Re: reducing NUMERIC size for 9.1 - Mailing list pgsql-hackers

From Brendan Jurd
Subject Re: reducing NUMERIC size for 9.1
Date
Msg-id AANLkTincjaM0KcL723jkAaRqmts7pUpHE3tw3LVMZo_3@mail.gmail.com
Whole thread Raw
In response to Re: reducing NUMERIC size for 9.1  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: reducing NUMERIC size for 9.1
Re: reducing NUMERIC size for 9.1
List pgsql-hackers
On 16 July 2010 03:47, Robert Haas <robertmhaas@gmail.com> wrote:
> On Jul 15, 2010, at 11:58 AM, Brendan Jurd <direvus@gmail.com> wrote:
>> I dropped one thousand numerics with value zero into a table and
>> checked the on-disk size of the relation with your patch and on a
>> stock 8.4 instance.  In both cases the result was exactly the same.
>>
>> Shouldn't the table be smaller with your patch?  Or is there something
>> wrong with my test?
>
> Well, on that test, you'll save only 2000 bytes, which is less than a full block, so there's no guarantee the
differencewould be noticeable at the relation level.  Scale it up by a factor of 10 and the difference should be
measurable.
>
> You might also look at testing with pg_column_size().
>

pg_column_size() did return the results I was expecting.
pg_column_size(0::numeric) is 8 bytes on 8.4 and it's 6 bytes on HEAD
with your patch.

However, even with 1 million rows of 0::numeric in my test table,
there was no difference at all in the on-disk relation size (36290560
with 36249600 in the table and 32768 in the fsm).

At this scale we should be seeing around 2 million bytes saved, but
instead the tables are identical.  Is there some kind of disconnect in
how the new short numeric is making it to the disk, or perhaps another
effect interfering with my test?

Cheers,
BJ


pgsql-hackers by date:

Previous
From: Markus Wanner
Date:
Subject: Re: SHOW TABLES
Next
From: Bruce Momjian
Date:
Subject: Re: SHOW TABLES