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