Re: Progress on fast path sorting, btree index creation time
Peter Geoghegan <peter@2ndquadrant.com>
From: Peter Geoghegan <peter@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Noah Misch <noah@leadboat.com>, Jay Levitt <jay.levitt@gmail.com>, "Jim Decibel! Nasby" <decibel@decibel.org>, Bruce Momjian <bruce@momjian.us>, Tom Lane <tgl@sss.pgh.pa.us>, PG Hackers <pgsql-hackers@postgresql.org>
Date: 2012-02-16T00:02:48Z
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
On 15 February 2012 15:27, Robert Haas <robertmhaas@gmail.com> wrote: >> I am inclined to agree that given that we already use Perl to generate >> source code like this, it seems natural that we should prefer to do >> that, if only to avoid paranoia about the inclusion of a dial-a-bloat >> knob. I am at a disadvantage here, since I've never written a line of >> Perl. > > I think it's still dial-a-bloat, but I feel pretty comfortable about > how we've got that knob adjusted in this version. It's almost as much > improvement as any previous version, it applies to more cases, and the > code footprint is the least of any version I've measured. I'm happy that the principle that a dial-a-bloat knob isn't necessarily a bad thing has been accepted, though that term is kind of pejorative in that it implies that the knob necessarily adds bloat to the binary. I define bloat here as the addition of dead instructions to the binary, or at least code that doesn't pull its weight. Clearly, that isn't the case here, and I suspect that we will find that it isn't the case in other places too. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services