Re: reducing NUMERIC size for 9.1

Поиск
Список
Период
Сортировка
От Brendan Jurd
Тема Re: reducing NUMERIC size for 9.1
Дата
Msg-id AANLkTincjaM0KcL723jkAaRqmts7pUpHE3tw3LVMZo_3@mail.gmail.com
обсуждение исходный текст
Ответ на Re: reducing NUMERIC size for 9.1  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: reducing NUMERIC size for 9.1  (Richard Huxton <dev@archonet.com>)
Re: reducing NUMERIC size for 9.1  (Hitoshi Harada <umi.tanuki@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Markus Wanner
Дата:
Сообщение: Re: SHOW TABLES
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: SHOW TABLES