Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <peter@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, PG Hackers <pgsql-hackers@postgresql.org>
Date: 2012-01-06T18:45:23Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. During btree index build, sort equal-keyed tuples according to their

Peter Geoghegan <peter@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