Re: Re: Abbreviated keys for Datum tuplesort

On Thu, Apr 2, 2015 at 5:34 PM, Peter Geoghegan <pg(at)heroku(dot)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