From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Reducing NUMERIC size for 8.3 |
Date: | 2007-07-17 22:01:41 |
Message-ID: | 200707172201.l6HM1f226532@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2007-07-17 23:05:17 | Re: lazy vacuum sleeps with exclusive lock on table |
Previous Message | Bruce Momjian | 2007-07-17 21:46:45 | Re: Updated tsearch documentation |