Re: [HACKERS] Index creation takes for ever

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