Index correlation (was: Moving postgresql.conf tunables into 2003... )

Поиск
Список
Период
Сортировка
От Manfred Koizar
Тема Index correlation (was: Moving postgresql.conf tunables into 2003... )
Дата
Msg-id 24k7jv4c62amkgq42ouh4csrjuu5c6s1q4@4ax.com
обсуждение исходный текст
Ответ на Re: Moving postgresql.conf tunables into 2003...  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
On Thu, 07 Aug 2003 19:31:52 -0400, Tom Lane <tgl@sss.pgh.pa.us>
wrote:
>The correlation is between index order and heap order --- that is, are
>the tuples in the table physically in the same order as the index?
>The better the correlation, the fewer heap-page reads it will take to do
>an index scan.

This is true for a column that is the first column of a btree index.
Correlation doesn't help with additional index columns and with
functional indices.

>Note it is possible to measure correlation without regard to whether
>there actually is any index;

But there is no need to, because the correlation is only used for
index access cost estimation.

>One problem we have is extrapolating from the single-column correlation
>stats computed by ANALYZE to appropriate info for multi-column indexes.
>It might be that the only reasonable fix for this is for ANALYZE to
>compute multi-column stats too when multi-column indexes are present.

I wonder whether it would be better to drop column correlation and
calculate index correlation instead, i.e. correlation of index tuples
to heap tuple positions.  This would solve both the multi-column index
and the functional index cost estimation problem.

>People are used to the assumption that you don't need to re-ANALYZE
>after creating a new index, but maybe we'll have to give that up.

Index correlation would be computed on CREATE INDEX and whenever the
heap relation is analysed ...

Servus
 Manfred

В списке pgsql-performance по дате отправления:

Предыдущее
От: Jonathan Gardner
Дата:
Сообщение: Re: Perfomance Tuning
Следующее
От: Andrew Sullivan
Дата:
Сообщение: Re: Perfomance Tuning