Re: Many-to-many performance problem

From: Yves Dorfsman <yves(at)zioup(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Many-to-many performance problem
Date: 2016-06-10 14:27:12
Message-ID: 575ACE40.8070703@zioup.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


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(at)gmail(dot)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.559 rows=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-10 07: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 on that lookup)?
Is the 18ms from the Buffers: read=3235? That's 3235 rows read from disk?

--
http://yves.zioup.com
gpg: 4096R/32B0F416

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2016-06-10 15:23:42 Re: Many-to-many performance problem
Previous Message Tom Lane 2016-06-10 14:13:45 Re: Many-to-many performance problem