I thought this was a really interesting case, and would love to learn from it, please bare with me if my questions are
naive.
On 2016-06-10 08:13, Tom Lane wrote:
> Rowan Seymour <rowanseymour@gmail.com> writes:
>> Most of time, this query performs like https://explain.depesz.com/s/ksOC
>> (~15ms). It's no longer using the using the msgs_inbox index, but it's
>> plenty fast. However, sometimes it performs like
>> https://explain.depesz.com/s/81c (67000ms)
>> And if you run it again, it'll be fast again.
>
> It looks like everything is fine as long as all the data the query needs
> is already in PG's shared buffers. As soon as it has to go to disk,
> you're hurting, because disk reads seem to be taking ~10ms on average.
-> Index Scan using msgs_message_pkey on msgs_message (cost=0.43..8.04 rows=1 width=47) (actual
time=18.550..18.559rows=0 loops=3556)
Index Cond: (id = msgs_message_labels.message_id)
Filter: (is_active AND is_handled AND has_labels AND (NOT is_archived) AND (created_on <
'2016-06-1007:11:06.381+00'::timestamp with time zone) AND (org_id = 7))
Rows Removed by Filter: 1
Buffers: shared hit=11032 read=3235 dirtied=5
Do you mean that it reads the index from disk? Or that it looks things up in the index, and fetch data on disk (based
onthat lookup)?
Is the 18ms from the Buffers: read=3235? That's 3235 rows read from disk?
--
http://yves.zioup.com
gpg: 4096R/32B0F416
