Re: [PATCHES] Index creation takes for ever

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCHES] Index creation takes for ever
Дата
Msg-id 14194.1062951808@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCHES] Index creation takes for ever  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: [PATCHES] Index creation takes for ever  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [PATCHES] Index creation takes for ever  (Manfred Koizar <mkoi-pg@aon.at>)
Список pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>>> * Order duplicate index entries by tid for faster heap lookups
>
>> I don't know why that TODO entry exists, but I think the idea is
>> counterproductive.

> I assume you are talking about a unique index that probably only has a
> few non-expired rows (in which case the newer rows first is better).
> The TODO deals with cases where you have lots of valid duplicate index
> rows, and you want to spin through all the matching rows in heap order
> rather than randomly.

Maybe so, but it would degrade the performance in the unique-index case
if we do it as the TODO is worded.

My own opinion is that the bitmap-index-lookup approach will be superior
to trying to keep the index entries in TID order.  (That's the idea
we've been discussing for awhile of separating the heap-fetch stage from
the index-scan stage: scan the index, make a sparse bitmap of the TIDs
we need to visit, possibly AND or OR this bitmap with maps derived from
other indexes, and finally visit the rows in heap order.)

            regards, tom lane

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

Предыдущее
От: Andreas Pflug
Дата:
Сообщение: Re: pg_id and pg_encoding
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [PATCHES] Index creation takes for ever