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

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.

regards, tom lane