From: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> |
---|---|
To: | Brendan Jurd <direvus(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: reducing NUMERIC size for 9.1 |
Date: | 2010-07-16 17:03:03 |
Message-ID: | AANLkTinnsrHj5EfHKDAhp99o2tb_NJH0rdpb7ez5X4tw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2010/7/16 Brendan Jurd <direvus(at)gmail(dot)com>:
> On 16 July 2010 03:47, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> 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?
What about large ARRAY of numeric type? Once upon a time I develop
tinyint for myself, the array size could get reduced.
Regards,
--
Hitoshi Harada
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2010-07-16 17:05:35 | Re: putting plproxy in pg_pltemplate |
Previous Message | Matthew Wakeling | 2010-07-16 16:56:52 | Trouble with COPY IN |