| 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: | Whole Thread | Raw Message | 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
| 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? |