Re: pg_restore real file size

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.

In response to

Browse pgsql-general by date

  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