On Mon, Mar 23, 2015 at 5:41 PM, Andrew Gierth <and...@tao11.riddles.org.uk> wrote: >>>>>> "Peter" == Peter Geoghegan <p...@heroku.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
