Re: [HACKERS] Index creation takes for ever

From: Manfred Koizar <mkoi-pg(at)aon(dot)at>
To: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
Cc: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-patches(at)postgresql(dot)org>, <ohp(at)pyrenet(dot)fr>, "pgsql-hackers list" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Index creation takes for ever
Date: 2003-09-08 11:27:28
Message-ID: 8jpolvkcufiq3gieo0pt6503ub8tim2bqm@email.aon.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Mon, 8 Sep 2003 11:31:05 +0200, "Zeugswetter Andreas SB SD"
<ZeugswetterA(at)spardat(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Joseph Krogh 2003-09-08 12:45:41 on-disk format changes
Previous Message ohp 2003-09-08 10:54:52 Re: Unixware 713 probs

Browse pgsql-patches by date

  From Date Subject
Next Message Kris Jurka 2003-09-08 12:17:52 SQLState implementation for V3 Protocol
Previous Message ohp 2003-09-08 10:54:52 Re: Unixware 713 probs