Re: Interesting slow query
От | Tom Lane |
---|---|
Тема | Re: Interesting slow query |
Дата | |
Msg-id | 13392.1150152788@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Interesting slow query (PFC <lists@peufeu.com>) |
Ответы |
Re: Interesting slow query
|
Список | pgsql-performance |
PFC <lists@peufeu.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
В списке pgsql-performance по дате отправления: