Re: Interesting slow query

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: PFC <lists(at)peufeu(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Interesting slow query
Date: 2006-06-12 22:53:08
Message-ID: 13392.1150152788@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

PFC <lists(at)peufeu(dot)com> writes:
> Here are two ways to phrase a query... the planner choses very different
> plans as you will see. Everything is freshly ANALYZEd.

Usually we get complaints the other way around (that the NOT EXISTS
approach is a lot slower). You did not show any statistics, but I
suspect the key point here is that the condition id > 1130306 excludes
most or all of the A and D tables. The planner is not smart about
making transitive inequality deductions, but you could help it along
by adding the implied clauses yourself:

EXPLAIN ANALYZE SELECT r.* FROM raw_annonces r
LEFT JOIN annonces a ON (a.id=r.id AND a.id > 1130306)
LEFT JOIN archive_data d ON (d.id=r.id AND d.id > 1130306)
WHERE a.id IS NULL AND d.id IS NULL AND r.id > 1130306
order by id limit 1;

Whether this is worth doing in your app depends on how often you do
searches at the end of the ID range ...

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Josh Berkus 2006-06-12 23:16:35 Re: 64-bit vs 32-bit performance ... backwards?
Previous Message Anthony Presley 2006-06-12 22:28:02 64-bit vs 32-bit performance ... backwards?