explain (analyze,buffers) SELECT u.userid,u.autologout,s.lastaccess FROM sessions s,users u WHERE s.sessionid='37510062db30b198bc1a9bab8a797308' AND s.status=0 AND s.userid=u.userid AND (s.lastaccess+u.autologout>1470303810 OR u.autologout=0);
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------
Nested Loop (cost=0.70..16.76 rows=1 width=16) (actual time=0.157..0.158 rows=1 loops=1)
Buffers: shared hit=5 read=2
-> Index Scan using sessions_pkey on sessions s (cost=0.55..8.57 rows=1 width=12) (actual time=0.131..0.131 rows=1 loops=1)
Index Cond: ((sessionid)::text = '37510062db30b198bc1a9bab8a797308'::text)
Filter: (status = 0)
Buffers: shared hit=3 read=2
-> Index Scan using users_pkey on users u (cost=0.14..8.17 rows=1 width=12) (actual time=0.024..0.025 rows=1 loops=1)
Index Cond: (userid = s.userid)
Filter: (((s.lastaccess + autologout) > 1470303810) OR (autologout = 0))
Buffers: shared hit=2
Total runtime: 0.209 ms
(11 rows)

IMHO план как план, однако при этом в логе
duration: 11415.247 ms

Меня терзают смутные сомнения , что дело совсем не в плане и нужно внимательнее смотреть, что там с IO, потому, что ничего криминального в плане добавить/изменить индекс на мой малоопытный взгляд не наблюдается.

Может я чего не заметил , что скажете ?

vyegorovrinace,

Нужно смотреть чем сервер занимался в такие моменты. Контрольная точка? pdflush?
По контрольной точке
------------------------------------------------------------------------------
name | checkpoint_completion_target
setting | 0.9

name | checkpoint_segments
setting | 256

name | checkpoint_timeout
setting | 3600

name | checkpoint_warning
setting | 30

По pdflush - спасибо за наводку