Re: Reducing NUMERIC size for 8.3 - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Reducing NUMERIC size for 8.3
Date
Msg-id 200707172201.l6HM1f226532@momjian.us
Whole thread Raw
In response to Reducing NUMERIC size for 8.3  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-hackers
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---------------------------------------------------------------------------

Simon Riggs wrote:
> We've changed the on-disk database format in 8.3, so we have an
> opportunity to change other things also. There is a patch thats been on
> the patch queue for some time called numeric508, submitted Dec 2005;
> I've updated this patch now for 8.3 to remove bit rot (an hour's work).
> This is posted to pgsql-patches now and it works.
> 
> The benefit of the patch is that it reduces each NUMERIC value by 2
> bytes, so will speed up things considerably. This is now especially
> important if we are looking to reduce the speed of numeric division by a
> factor of 4 (recent WIP patch).
> 
> The objections to applying this patch originally were:
> 1. it changes on-disk format (we've done this, so argument is void)
> 2. it would restrict number of digits to 508 and there are allegedly
> some people that want to store > 508 digits.
> 
> The current patch passes all regression tests, but currently fails
> numeric_big.sql since this explicitly checks for support of
> numeric(1000,800).
> 
> We could:
> a) accept the patch as-is and restrict NUMERIC to 508 digits
> b) refine the patch somewhat to allow 1000 digits
> 
> (b) is possible in a couple of ways, both fairly quick:
> - extend the patch so that one of the spare bits from the second digit
> is used to represent dscale 508-1000. 
> - extend the patch so that if weight > 127 or dscale > 127 we would use
> the first byte in the digits as an extra indicator byte holding the high
> bits of both fields.
> Neither change makes any difference to numbers below
> 1,000,000,000,000,000....(127 zeroes in total)...000 which probably
> covers the vast majority of people's usage.
> 
> Objections: True, we are passed feature freeze, but this patch has been
> on the queue for 14 months prior to freeze and has been waiting on disk
> format changes to make patch application acceptable. We definitely want
> to reduce the size of Numeric by 2 bytes at some point. The question in
> my mind is: When is the best time to make this change? If we put this
> off until 8.4, then it will get rejected again because we won't want to
> change the disk format again. So the best time to do this is now,
> otherwise we'll put it off forever.
> 
> Can I get somebody other than Tom to agree to review the patch? Clearly
> waiting for Tom to review this is just going to delay release, which I
> don't want to do.
> 
> -- 
>   Simon Riggs             
>   EnterpriseDB   http://www.enterprisedb.com
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Updated tsearch documentation
Next
From: Bruce Momjian
Date:
Subject: Re: lazy vacuum sleeps with exclusive lock on table