Re: Determining size of a database before dumping

Поиск
Список
Период
Сортировка
От Alexander Staubo
Тема Re: Determining size of a database before dumping
Дата
Msg-id F3044600-A99E-4A32-BE3B-4063EB8A5DD8@purefiction.net
обсуждение исходный текст
Ответ на Re: Determining size of a database before dumping  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Determining size of a database before dumping  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-general
On Oct 2, 2006, at 23:19 , Tom Lane wrote:

> Alexander Staubo <alex@purefiction.net> writes:
>> You could count the disk space usage of the actual stored tuples,
>> though this will necessarily be inexact:
>>    http://www.postgresql.org/docs/8.1/static/diskusage.html
>> Or you could count the size of the physical database files (/var/lib/
>> postgresql or wherever). While these would be estimates, you could at
>> least guarantee that the dump would not *exceed* the esimtate.
>
> You could guarantee no such thing; consider compression of TOAST
> values.
> Even for uncompressed data, datatypes such as int and float can easily
> print as more bytes than they occupy on-disk.

Why does pg_dump serialize data less efficiently than PostgreSQL when
using the "custom" format? (Pg_dump arguably has greater freedom in
being able to apply space-saving optimizations to the output format.
For example, one could use table statistics to selectively apply
something like Rice coding for numeric data, or vertically decompose
the tuples and emit sorted vectors using delta compression.) As for
TOAST, should not pg_dump's compression compress just as well, or
better?

Alexander.

В списке pgsql-general по дате отправления:

Предыдущее
От: "Aaron Glenn"
Дата:
Сообщение: Experiences with 3PAR
Следующее
От: Ron Johnson
Дата:
Сообщение: Re: Determining size of a database before dumping