Re: [PATCHES] Index creation takes for ever - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] Index creation takes for ever
Date
Msg-id 14194.1062951808@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] Index creation takes for ever  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [PATCHES] Index creation takes for ever
Re: [PATCHES] Index creation takes for ever
List 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 by date:

Previous
From: Andreas Pflug
Date:
Subject: Re: pg_id and pg_encoding
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] Index creation takes for ever