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

From Zeugswetter Andreas SB SD
Subject Re: Index creation takes for ever
Date
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA4961FFD@m0114.s-mxs.net
Whole thread Raw
In response to Index creation takes for ever  (ohp@pyrenet.fr)
Responses Re: Index creation takes for ever  (Manfred Koizar <mkoi-pg@aon.at>)
List pgsql-hackers
> > I don't think so, because the patch does nothing to keep the sort
> > order once the index is initially created.
>
> As Tom mentioned, we might not want to keep the tid's in order after the
> index is created because he wants the most recent tid's first, so the
> expired ones migrate to the end.

But on average this argument only holds true for unique indexes, no ?
Is there any code that stops the heap lookup after the visible tuple is found ?
At least in an index with more rows per key you will fetch all heaps after the
first one anyway to get at the next row. This is better done in heap order, no ?

And the bitmap approach will not work for large result sets.

Summa summarum I would leave the TODO item (maybe add a comment
(only for non-unique, evaluate performance))

Andreas

pgsql-hackers by date:

Previous
From: Mark Kirkwood
Date:
Subject: dump cache summary
Next
From: "Gaetano Mendola"
Date:
Subject: Re: mcxt.c