Re: Abbreviated keys for Numeric (was: Re: B-Tree support function number 3 (strxfrm() optimization))
От | Tomas Vondra |
---|---|
Тема | Re: Abbreviated keys for Numeric (was: Re: B-Tree support function number 3 (strxfrm() optimization)) |
Дата | |
Msg-id | 54E7D48E.6020908@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Abbreviated keys for Numeric (was: Re: B-Tree support function number 3 (strxfrm() optimization)) (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: Abbreviated keys for Numeric (was: Re: B-Tree support
function number 3 (strxfrm() optimization))
|
Список | pgsql-hackers |
On 21.2.2015 01:17, Peter Geoghegan wrote: > 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. 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
В списке pgsql-hackers по дате отправления: