From: | Alban Hertroys <haramrae(at)gmail(dot)com> |
---|---|
To: | John R Pierce <pierce(at)hogranch(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: pg_restore real file size |
Date: | 2016-02-26 08:18:09 |
Message-ID: | 6F5AFC4C-5996-4819-9E98-B11900D9FCEE@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> On 26 Feb 2016, at 5:30, John R Pierce <pierce(at)hogranch(dot)com> wrote:
>
> On 2/25/2016 8:26 PM, drum(dot)lucas(at)gmail(dot)com wrote:
>>
>> I'm doing the pg_restore now in a 1.5TB file:
>>
>> # ls -la
>> postgres postgres 1575324616939 Feb 20 13:55 devdb_0.sql
>>
>> But, the restore has gone over 1.6 TB
>>
>
> the dump file does not contain the indexes, just CREATE INDEX statements
Or page alignment padding, or the effects of fill factors, to name a few more reasons.
Besides, your dump-file is compressed. It's being restored using pg_restore (or can it restore using plain text sql scripts these days?) instead of psql.
Lastly, how does a database in unicode fare for text size (without toasted values) against a plain text dump file in, say, utf-8 - which isn't even the worst case scenario? That's the simplistic case; in reality some values will get toasted and the dump file is compressed.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll find there is no forest.
From | Date | Subject | |
---|---|---|---|
Next Message | Bryan Ellerbrock | 2016-02-26 15:00:48 | Re: Privileges granted on dblink extension function do not survive database dump and restore |
Previous Message | Shulgin, Oleksandr | 2016-02-26 08:11:40 | Re: pg_restore real file size |