Re: Progress on fast path sorting, btree index creation time
Tom Lane <tgl@sss.pgh.pa.us>
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-06T21:14:27Z
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 →
-
During btree index build, sort equal-keyed tuples according to their
- fbac1272b89b 8.0.0 cited
Peter Geoghegan <peter@2ndquadrant.com> writes: > On 6 January 2012 18:45, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 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? When there are lots of duplicates of a particular indexed value, the existing code will cause an indexscan to search them in physical order, whereas if we remove the existing logic it'll be random --- in particular, accesses to the same heap page can no longer be expected to be clustered. Admittedly, I don't have any numbers quantifying just how useful that might be, but on the other hand you've not presented any evidence justifying removing the behavior either. If we believe your position that indexes don't generally have lots of duplicates, then the code in question will seldom be reached and therefore there would be no performance benefit in removing it. regards, tom lane