
> > 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

Mon, 8 Sep 2003 11:31:05 +0200
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: [HACKERS] Index creation takes for ever
On Mon, 8 Sep 2003 11:31:05 +0200, "Zeugswetter Andreas SB SD"
<ZeugswetterA@spardat.at> wrote:
>> 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 ?

Yes, yes, yes, and yes.  Seems we all agree on that; the patch has
been queued for 7.5.

Servus
 Manfred

Mon, 08 Sep 2003 13:27:28 +0200
Manfred Koizar <mkoi-pg@aon.at>
Re: [HACKERS] Index creation takes for ever