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
