Added to TODO:
* Consider whether duplicate keys should be sorted by block/offset
http://archives.postgresql.org/pgsql-hackers/2008-03/msg00558.php
---
Tom Lane wrote:
There are several places in tuplesort.c (and
Bruce Momjian [EMAIL PROTECTED] writes:
Tom, are you intending to remove this part of the sort code?
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
Well, I got some push-back on the proposal, so I'd kind of dropped it.
But AFAIR the objections were purely hypothetical, whereas the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom, are you intending to remove this part of the sort code?
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
Well, I got some push-back on the proposal, so I'd kind of dropped it.
But AFAIR the objections were purely
Tom, are you intending to remove this part of the sort code?
---
Tom Lane wrote:
There are several places in tuplesort.c (and perhaps elsewhere) where
we explicitly work around limitations of various platforms' qsort()
How about always adding the TID as last key when using qsort for
create
index ?
I think you misunderstood: that's what we do now. I'm proposing
removing it because I think it's probably useless.
Ah, sorry, I did not look at the code, and interpreted your comment as
some exceptional
2. If you've got lots of equal keys, it's conceivable that having the
index entries sorted by TID offers some advantage in indexscan speed.
I'm dubious that that's useful, mainly because the planner should
prefer
a bitmap scan in such a case; and anyway the ordering is unlikely to
be
Tom Lane wrote:
There are several places in tuplesort.c (and perhaps elsewhere) where
we explicitly work around limitations of various platforms' qsort()
functions. Notably, there's this bit in comparetup_index_btree
/*
* If key values are equal, we sort on ItemPointer. This does
Zeugswetter Andreas OSB SD [EMAIL PROTECTED] writes:
How about always adding the TID as last key when using qsort for create
index ?
I think you misunderstood: that's what we do now. I'm proposing
removing it because I think it's probably useless.
regards, tom lane
--
There are several places in tuplesort.c (and perhaps elsewhere) where
we explicitly work around limitations of various platforms' qsort()
functions. Notably, there's this bit in comparetup_index_btree
/*
* If key values are equal, we sort on ItemPointer. This does not affect
*
