Re: [HACKERS] Index creation takes for ever

Here is more detail on the patch.

---------------------------------------------------------------------------

Manfred Koizar wrote:
> On Mon, 1 Dec 2003 00:02:54 -0500 (EST), Bruce Momjian
> <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:
> >Tom Lane wrote:
> >> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> >> >> And if it doesn't help index
> >> >> creation speed, at least the resulting index has better correlation.
>
> ... which has been shown by the example in the original message:
> > Result without patch:
> > ctid
> > ----------
> > (153,14)
> > (306,23)
> > (305,80)
> > (152,91)
> > (76,68)
> > (38,34)
> > (153,34)
> > (305,50)
> > (9,62)
> > (305,40)
> > (10 rows)
> >
> > Result with patch:
> > ctid
> > --------
> > (0,5)
> > (0,10)
> > (0,15)
> > (0,20)
> > (0,25)
> > (0,30)
> > (0,35)
> > (0,40)
> > (0,45)
> > (0,50)
> > (10 rows)
>
> And I think we all agree, that better index correlation leads to better
> performance.
>
> >> I think this is a *very* dubious idea. It introduces a low-level
> >> implementation dependency into our sort behavior
>
> The patch modifies the static function comparetup_index() in
> tuplesort.c.
> The comment above this function says
> /*
> * Routines specialized for IndexTuple case
> *
> * NOTE: actually, these are specialized for the btree case; [...]
> */
>
> 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?
>
> >Roger --- patch removed. Thanks.
>
> Could we agree on only removing the first five a half lines of the
> comment in the patch?
>
> Servus
> Manfred
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073