Re: Progress on fast path sorting, btree index creation time

On 6 January 2012 18:45, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
>> I didn't bother isolating that, because it doesn't really make sense
>> to (not having it is probably only of particular value when doing what
>> I'm doing anyway, but who knows). Go ahead and commit something to
>> remove that code (get it in both comparetup_index_btree and
>> comparetup_index_hash), as well as the tuple1 != tuple2 test now if
>> you like. It's patently clear that it is unnecessary, and so doesn't
>> have to be justified as a performance enhancement - it's a simple case
>> of refactoring for clarity. As I've said, we don't do this for heap
>> tuples and we've heard no complaints in all that time. It was added in
>> commit fbac1272b89b547dbaacd78bbe8da68e5493cbda, presumably when
>> problems with system qsorts came to light.
>
> Actually, I'm going to object to reverting that commit, as I believe
> that having equal-keyed index entries in physical table order may offer
> some performance benefits at access time.  If you don't like the
> comment, we can change that.

Please explain your position. When is this supposed to be useful? Even
if you can present an argument for keeping it, it has to weigh the
fact that people don't tend to have much use for indexes with lots of
duplicates anyway. Prior to 2004, we did not do this - it was
justified as insurance against bad qsort implementations only.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services