Re: More tablescanning fun
От | Manfred Koizar |
---|---|
Тема | Re: More tablescanning fun |
Дата | |
Msg-id | iilvavo0jj8frdj6e9a9p6ise3gci5icj7@4ax.com обсуждение исходный текст |
Ответ на | Re: More tablescanning fun ("Jim C. Nasby" <jim@nasby.net>) |
Ответы |
Re: More tablescanning fun
|
Список | pgsql-performance |
On Fri, 25 Apr 2003 09:38:01 -0500, "Jim C. Nasby" <jim@nasby.net> wrote: >In this case, the interpolation can't be at fault, because correlation >is 1 (unless the interpolation is backwards, but that doesn't appear to >be the case). But your index has 3 columns which causes the index correlation to be assumed as 1/3. So the interpolation uses 1/9 (correlation squared) and you get a cost estimation that almost equals the upper bound. If you want to play around with other interpolation methods, you might want to get this patch: http://www.pivot.at/pg/16-correlation-732.diff A short description of the GUC parameters introduced by this patch can be found here: http://archives.postgresql.org/pgsql-performance/2002-11/msg00256.php As a short term workaround for an unmodified Postgres installation, you can create an index on email_contrib(project_id). Servus Manfred
В списке pgsql-performance по дате отправления: