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-12-02 09:24:30 |
Message-ID: | telosv8k2tgd5jajmgnrk5ce0op5fj6it8@email.aon.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On Mon, 01 Dec 2003 13:32:10 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
>> comparetup_index() compares two IndexTuples. The structure
>> IndexTupleData consists basically of not much more than an ItemPointer,
>> and the patch is not much more than adding a comparison of two
>> ItemPointers. So how does the patch introduce a new low level
>> implementation dependency?
>
>Because it sorts on tuple position, which is certainly about as low
>level as you can get.
The patch affects only the sort during index creation. Mapping key
values to tuple positions is the sole purpose of an index. The notion
that an index should not care for tuple positions looks a bit strange to
me.
> More to the point, though, no evidence has been
>provided that this is a good idea.
The test script I posted with the patch shows that the patch produces
more efficient b-tree indices when there are lots of duplicates.
Servus
Manfred
From | Date | Subject | |
---|---|---|---|
Next Message | Jean-Michel POURE | 2003-12-02 11:56:08 | Re: Copyright (C) 1996-2002 |
Previous Message | Neil Conway | 2003-12-02 06:30:11 | Re: [PATCH] Re: [pgsql-advocacy] Why READ ONLY |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2003-12-02 09:30:46 | Re: introduce "default_use_oids" |
Previous Message | Christopher Kings-Lynne | 2003-12-02 06:56:37 | Re: introduce "default_use_oids" |