Re: Slow 3 Table Join with v bad row estimate
| От | Igor Neyman |
|---|---|
| Тема | Re: Slow 3 Table Join with v bad row estimate |
| Дата | |
| Msg-id | A76B25F2823E954C9E45E32FA49D70ECCD583368@mail.corp.perceptron.com обсуждение исходный текст |
| Ответ на | Re: Slow 3 Table Join with v bad row estimate (David Osborne <david@qcode.co.uk>) |
| Ответы |
Re: Slow 3 Table Join with v bad row estimate
|
| Список | pgsql-performance |
From: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of David Osborne
Sent: Tuesday, November 10, 2015 12:32 PM
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Slow 3 Table Join with v bad row estimate
Ok - wow.
Adding that index, I get the same estimate of 1 row, but a runtime of ~450ms.
A 23000ms improvement.
This is great. So as a general rule of thumb, if I see a Join Filter removing an excessive number of rows, I can check if that condition can be added to an index from the same table which is already being scanned.
Thanks for this!
David,
I believe the plan you are posting is the old plan.
Could you please post explain analyze with the index that Tom suggested?
Regards,
Igor Neyman
В списке pgsql-performance по дате отправления: