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

From Martijn van Oosterhout
Subject Re: Reducing the overhead of NUMERIC data
Date
Msg-id 20051102204242.GG19550@svana.org
Whole thread Raw
In response to Re: Reducing the overhead of NUMERIC data  ("Jim C. Nasby" <jnasby@pervasive.com>)
List pgsql-hackers
On Wed, Nov 02, 2005 at 12:53:07PM -0600, Jim C. Nasby wrote:
> > This is one of those issues where we need to run tests and take input.
> > We cannot decide this sort of thing just by debate alone. So, I'll leave
> > this as a less potentially fruitful line of enquiry.
>
> Is it worth comming up with some script that users can run against a
> table to provide us with real data?

Like I said, I have a few columns of numeric(12,4). They're costs in
cent, to 4 decimal places. The test is (column = trunc(column)).

Sample data: col1   |  col2   |  col3  |  col4
---------+---------+--------+---------21.0000 | 10.1818 | 0.0000 | 21.000022.0000 | 11.2727 | 0.0000 | 22.000022.0000 |
6.0909 | 0.0000 | 22.0000 

For each column (across 17 million rows):

Col 1:  83%   trailing zeros
Col 2:  49%
Col 3:  94%
Col 4:  83%

AIUI, I currently get the four decimal places for free, and the idea is
to store them explicitly.

Fact is, things that cost fractions of cents are not that common, in
this database anyway. As for the argument in general, this table is so
wide that any gain will vanish into the slack at the end of a block so
it won't actually matter...

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_restore [archiver] file offset in dump file is too
Next
From: Robert Creager
Date:
Subject: Re: Assert failure found in 8.1RC1