Re: [HACKERS] Index creation takes for ever

From: Manfred Koizar <mkoi-pg(at)aon(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(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-07 17:35:55
Message-ID: 70qmlv8iq0nfhm5bqhlsful9335m6tdac5@4ax.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Sun, 07 Sep 2003 12:23:28 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
wrote:
>Maybe so, but it would degrade the performance in the unique-index case
>if we do it as the TODO is worded.

The patch would only hurt with a unique index, if there are lots of
duplicate tuples at CREATE INDEX time.

>My own opinion is that the bitmap-index-lookup approach will be superior

So is mine, but I was not able to do this in 30 lines. Sorry ;-)

>to trying to keep the index entries in TID order.
^^^^
... which the patch does not. I see its main advantage in creating
better b-tree indices when you restore a large database with many
duplicate index entries.

It is intended to be only effective at CREATE INDEX or REINDEX time.
I don't believe it is activated when you insert a single new entry,
otherwise it wouldn't pass regression tests ...

Servus
Manfred

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Pflug 2003-09-07 18:16:05 Re: pg_id and pg_encoding
Previous Message Gaetano Mendola 2003-09-07 17:30:52 Re: pg_id and pg_encoding

Browse pgsql-patches by date

  From Date Subject
Next Message ohp 2003-09-07 18:22:30 Unixware 713 probs
Previous Message Manfred Koizar 2003-09-07 17:16:24 Re: [HACKERS] Index creation takes for ever