On Mon, 2007-06-18 at 10:54 -0400, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > 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 thought that idea had been rejected long since as being an unreasonable
> reduction in the flexibility of numeric arithmetic.
I've re-read all of the posts from Dec 2005 and I see everyone in favour
of committing the patch, subject to review of whether limitation to 508
was acceptable. For me that was never finalised, at least I can't see a
clear decision. The important point is that the patch can be easily
modified to overcome these restrictions, a line of thought that was
never explored.
The current patch can be easily modified to allow 1000 digits, yet still
saving 2 bytes per value when storing more common values. Or we can use
the same techniques to represent arbitrary number of digits, again still
saving 2 bytes on common values.
We have the ground work done, we just need to agree further changes.
> > 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 only way that patch would make division faster is by making the
> slowest cases (longest input numbers) impossible. Which is hardly a
> solution.
It isn't directly related to division, but is a speed up nonetheless
which can offset the loss.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com