Re: Reducing the overhead of NUMERIC data - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Reducing the overhead of NUMERIC data
Date
Msg-id 1131006476.8300.1866.camel@localhost.localdomain
Whole thread Raw
In response to Re: Reducing the overhead of NUMERIC data  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Reducing the overhead of NUMERIC data  (Simon Riggs <simon@2ndquadrant.com>)
Re: Reducing the overhead of NUMERIC data  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Re: Reducing the overhead of NUMERIC data  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Wed, 2005-11-02 at 19:12 -0500, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > Could someone please quantify how much bang we might get for what seems 
> > like quite a lot of bucks?
> > I appreciate the need for speed, but the saving here strikes me as 
> > marginal at best, unless my instincts are all wrong (quite possible)
> 
> Two bytes per numeric value is not a lot, agreed.

I'm optimising for Data Warehousing. If you have a very large table with
a higher proportion of numerics on it, then your saving can be >5% of
tablesize which could be very useful. For the general user, it might
produce less benefit, I accept.

At the moment we've established we can do this fairly much for free.
i.e. nobody cares about the drop in digits (to 255) and the other coding
seems very minimal. I've accepted that the runtime costs are almost
zero. Even the coding is small, so we've talked more lines than the
patch already. Seems like a quick win; Tom is helping me to make sure it
is not a quick and dirty win and I very much appreciate that.

[I've taken this off -patches to show that we are not really discussing
minor mods to the original patch anymore.]

> If we were willing to invent the "varlena2" datum format then we could
> save four bytes per numeric, plus reduce numeric's alignment requirement
> from int to short which would probably save another byte per value on
> average.  I'm not sure that that's worth doing if numeric and inet are
> the only beneficiaries, but it might be.

That and variations can be the next discussion. They sound good.

Those ideas are complementary, if I understand them.

Best Regards, Simon Riggs



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Reducing the overhead of NUMERIC data
Next
From: Simon Riggs
Date:
Subject: Re: Reducing the overhead of NUMERIC data