Re: Abbreviated keys for Numeric (was: Re: B-Tree support function number 3 (strxfrm() optimization))

On 21.2.2015 01:17, Peter Geoghegan wrote:
> On Fri, Feb 20, 2015 at 4:11 PM, Tomas Vondra
> <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>>> So you're testing both the patches (numeric + datum tuplesort) at the
>>> same time?
>>
>> No, I was just testing two similar patches separately. I.e. master vs.
>> each patch separately.
>
> Well, you're sorting numeric here, no? Why should it matter that a
> datum sort has abbreviation support, if the underlying type (numeric)
> does not support abbreviation? OTOH, why should having oplcass
> abbreviation support (for numeric) matter if the class of tuple sorted
> (datum "tuples") does not support abbreviation? You need both to
> meaningfully benchmark either (as long as you're looking at a case
> involving both).
>
> I suggest looking at datum sorts with text for the datum sort patch,
> and non-datum tuplesort cases for the numeric patch, at least until
> such time as one or the other is committed.

Isn't this patch about adding abbreviated keys for Numeric data type?
That's how I understood it, and looking into numeric_sortsup.patch seems
to confirm that.

There's another patch for Datum, but that's a different thread.

--
Tomas Vondra http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services