Re: Can't explain db size

also,
serializable_value is of type bytea

2015-12-17 16:12 GMT+01:00 Matteo Grolla <matteo(dot)grolla(at)gmail(dot)com>:

> have news,
> the pg version is 9.1.3
> a vaccum full, not a plain vaccum, was performed.
> o.s. is red hat 7
> filesystem: xfs with block size 4k
>
> could it be a problem regarding the block size?
> thanks
>
> 2015-12-15 12:11 GMT+01:00 Matteo Grolla <matteo(dot)grolla(at)gmail(dot)com>:
>
>> Thanks Andreas,
>> Il try
>>
>> 2015-12-15 11:07 GMT+01:00 Andreas Kretschmer <akretschmer(at)spamfence(dot)net>
>> :
>>
>>> Matteo Grolla <matteo(dot)grolla(at)gmail(dot)com> wrote:
>>>
>>> >
>>> > -------Questions----------------
>>> >
>>> > 1) Can you explain me the big difference between the result in A for
>>> table
>>> > alf_node_properties: 17GB and the result in B: ~6GB ?
>>> >
>>> > 2) Can you explain me the difference between the result in B: ~6GB and
>>> the
>>> > result in C, the sum of all column sizes, 3717MB ?
>>>
>>> Maybe there are some dead tuples, run a VACUUM FULL (be careful, it
>>> requires an explicit lock). And please keep in mind that a table
>>> can contains indexes and other objects. A nice explanation and some ways
>>> to gather informations on table-, index- and database sizes can you find
>>> here:
>>>
>>> http://andreas.scherbaum.la/blog/archives/282-table-size,-database-size.html
>>>
>>>
>>> Regards, Andreas
>>> --
>>> Really, I'm not out to destroy Microsoft. That will just be a completely
>>> unintentional side effect. (Linus Torvalds)
>>> "If I was god, I would recompile penguin with --enable-fly." (unknown)
>>> Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°
>>>
>>>
>>> --
>>> Sent via pgsql-performance mailing list (
>>> pgsql-performance(at)postgresql(dot)org)
>>> To make changes to your subscription:
>>> http://www.postgresql.org/mailpref/pgsql-performance
>>>
>>
>>
>