From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Frank Lanitz <frank(at)frank(dot)uvena(dot)de> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: pg_database_size differs from df -s |
Date: | 2012-06-06 16:28:45 |
Message-ID: | 11737.1339000125@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Frank Lanitz <frank(at)frank(dot)uvena(dot)de> writes:
> Am 06.06.2012 17:49, schrieb Tom Lane:
>> For me, pg_database_size gives numbers that match up fairly well with
>> what "du" says. I would not expect an exact match, since du probably
>> knows about filesystem overhead (such as metadata) whereas
>> pg_database_size does not. Something's fishy if it's off by any large
>> factor, though. Perhaps you have some tables in a nondefault
>> tablespace, where du isn't seeing them?
> Nope. Its a pretty much clean database without any fancy stuff.
Peculiar. If you want to put some time into it, you could try comparing
sizes table-by-table to see if you can isolate where the discrepancy is.
The only reason I can think of for du to report a size smaller than the
nominal file length (which is which the pg_xxx_size functions look at)
is if the file contains unallocated "holes". That really shouldn't ever
happen with PG tables though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Lonni J Friedman | 2012-06-06 16:42:50 | Re: pg_basebackup blocking all queries |
Previous Message | Benson Jin | 2012-06-06 16:20:06 | Need help in transferring FP to Int64 DateTime |