Re: Abbreviated keys for Numeric

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
Subject: Re: Abbreviated keys for Numeric
Date: 2015-03-23 21:41:40
Message-ID: 87a8z39zk8.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "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?

--
Andrew (irc:RhodiumToad)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2015-03-23 21:42:37 Re: logical column ordering
Previous Message Josh Berkus 2015-03-23 21:40:29 Re: logical column ordering