Re: Abbreviated keys for Numeric

On Mon, Mar 23, 2015 at 5:41 PM, Andrew Gierth
<andrew(at)tao11(dot)riddles(dot)org(dot)uk> wrote:
>>>>>> "Peter" == Peter Geoghegan <pg(at)heroku(dot)com> writes:
>
> Peter> As I said, I don't really consider that my patch is a rewrite,
> Peter> especially V4, which changes nothing substantive except removing
> Peter> 32-bit support.
>
> Well, that's a hell of an "except".
>
> Here's my main arguments for why 32bit support should be kept:
>
> 1. It exists and works well (and yes, I have tested it).
>
> 2. This optimization is a huge win even on very small data sets. On
> sorts of as few as 100 items it gives detectable (on the order of +50%)
> improvements. On 1000 items the speedup can easily be 3 times. So it's
> not just people with big data who want this; even small databases will
> benefit.
>
> 3. Keeping the 32bit support (and desupporting DEC_DIGITS != 4) makes it
> unnecessary to have #ifdefs that disable the numeric abbreviation
> entirely. (You don't even need those for comparative performance
> testing; easier to do that by tweaking the catalogs.)
>
> As against that, you have the fact that it's ~70 lines of code in one
> self-contained function which is 32bit-specific.
>
> So what do other people think?

I agree with you. Fewer and fewer people are running 32-bit systems
these days, but there must surely be more people running 32-bit
systems than there are running with DEC_DIGITS != 4. I think it's a
stretch to say that DEC_DIGITS != 4 is "supported" in any meaningful
sense, so I don't think de-supporting it is an issue.

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