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

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>

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

Cc: Peter Geoghegan <peter@2ndquadrant.com>, Jay Levitt <jay.levitt@gmail.com>, "Jim \"Decibel!\" Nasby" <decibel@decibel.org>, Bruce Momjian <bruce@momjian.us>, PG Hackers <pgsql-hackers@postgresql.org>

Date: 2012-02-08T15:17:36Z

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 Wed, Feb 8, 2012 at 9:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> IMO this patch is already well past the point of diminishing returns in
> value-per-byte-added.  I'd like to see it trimmed back to provide a fast
> path for just single-column int4/int8/float4/float8 sorts.  The other
> cases aren't going to offer enough of a win to justify the code space.

I'm curious about how much we're gaining from the single-column
specializations vs. the type-specific specializations.  I think I'm
going to go try to characterize that.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company