Re: Re: Abbreviated keys for Datum tuplesort - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Re: Abbreviated keys for Datum tuplesort
Date
Msg-id CA+TgmoZ+=xojW1bLOTbaFdh7Jks5=QJC=ocj+yCdtiktrbenTg@mail.gmail.com
Whole thread Raw
In response to Re: Re: Abbreviated keys for Datum tuplesort  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Re: Abbreviated keys for Datum tuplesort
Re: Re: Abbreviated keys for Datum tuplesort
List pgsql-hackers
On Thu, Apr 2, 2015 at 5:34 PM, Peter Geoghegan <pg@heroku.com> wrote:
> I think it's explained by the pre-check for sorted input making the
> number of comparisons exactly n -1. As I pointed out to Tomas, if you
> put a single, solitary unsorted element at the end, the abbreviated
> version is then 8x faster (maybe that was in relation to a slightly
> different case, but the pattern is the same). So this case isn't an
> argument against datum abbreviation, or even abbreviation in general,
> but rather an argument against using strxfrm() in general (which for
> example the GCC docs strongly recommend for sorting lists of strings).
> It's a bad argument, IMV. This sort is already extremely fast.

OK, I see.

> The changes that Andrew
> took issue with are utterly insignificant.

Great.  Then you will be utterly indifferent to which version gets committed.

> Also, the changes that Andrew didn't mention are clearly appropriate.
> In particular, the comments on the SortKeys variable being used by
> every case except the hash case and datum case should still be updated
> to reflect that that's only true for the hash case now.

On that point, I agree.

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



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: TABLESAMPLE patch
Next
From: Robert Haas
Date:
Subject: Re: What exactly is our CRC algorithm?