Horton

Re: sortsupport for text

Noah Misch <noah@leadboat.com>

View thread
From: Noah Misch <noah@leadboat.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2012-03-08T15:19:42Z
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. Adjust string comparison so that only bitwise-equal strings are considered

  2. Add operator strategy and comparison-value datatype fields to ScanKey.

On Fri, Mar 02, 2012 at 03:45:38PM -0500, Robert Haas wrote:
> SELECT SUM(1) FROM (SELECT * FROM randomtext ORDER BY t) x;
> 
> On unpatched master, this takes about 416 ms (plus or minus a few).
> With the attached patch, it takes about 389 ms (plus or minus a very
> few), a speedup of about 7%.
> 
> I repeated the experiment using the C locale, like this:
> 
> SELECT SUM(1) FROM (SELECT * FROM randomtext ORDER BY t COLLATE "C") x;
> 
> Here, it takes about 202 ms with the patch, and about 231 ms on
> unpatched master, a savings of about 13%.

> [oprofile report, further discussion]

Thanks for looking into this.  Your patch is also a nice demonstration of
sortsupport's ability to help with more than just fmgr overhead.

> Considering all that, I
> had hoped for more like a 15-20% gain from this approach, but it
> didn't happen, I suppose because some of the instructions saved just
> resulted in more processor stalls.  All the same, I'm inclined to
> think it's still worth doing.

This is a border case, but I suggest that a 13% speedup on a narrowly-tailored
benchmark, degrading to 7% in common configurations, is too meager to justify
adopting this patch.

nm