also, serializable_value is of type bytea 2015-12-17 16:12 GMT+01:00 Matteo Grolla <matteo.gro...@gmail.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.gro...@gmail.com>: > >> Thanks Andreas, >> Il try >> >> 2015-12-15 11:07 GMT+01:00 Andreas Kretschmer <akretsch...@spamfence.net> >> : >> >>> Matteo Grolla <matteo.gro...@gmail.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@postgresql.org) >>> To make changes to your subscription: >>> http://www.postgresql.org/mailpref/pgsql-performance >>> >> >> >