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  ("Jim C. Nasby" <jim@nasby.net>)
Список 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 по дате отправления:

Предыдущее
От: "SZŰCS Gábor"
Дата:
Сообщение: Re: Query Plan far worse in 7.3.2 than 7.2.1
Следующее
От: Stephan Szabo
Дата:
Сообщение: Re: Why LIMIT after scanning the table?