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
|
Список | 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 по дате отправления: