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

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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"