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

From Peter Geoghegan
Subject Re: Abbreviated keys for Numeric (was: Re: B-Tree support function number 3 (strxfrm() optimization))
Date
Msg-id CAM3SWZQWq5h8_7eKS0ZW6yCk3GQ_3A268v23z5A7ZVSFxu457Q@mail.gmail.com
Whole thread Raw
In response to Re: Abbreviated keys for Numeric (was: Re: B-Tree support function number 3 (strxfrm() optimization))  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: Abbreviated keys for Numeric (was: Re: B-Tree support function number 3 (strxfrm() optimization))
List pgsql-hackers
On Fri, Feb 20, 2015 at 4:11 PM, Tomas Vondra
<tomas.vondra@2ndquadrant.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.
-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Abbreviated keys for Numeric (was: Re: B-Tree support function number 3 (strxfrm() optimization))
Next
From: Tomas Vondra
Date:
Subject: Re: Idea: GSoC - Query Rewrite with Materialized Views