Re: Reducing NUMERIC size for 8.3

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. +

In response to

Browse pgsql-hackers by date

  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