On Mon, 1 Dec 2003 00:02:54 -0500 (EST), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
