Peter Geoghegan <pe...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers