Re: Can't explain db size - Mailing list pgsql-performance

From Matteo Grolla
Subject Re: Can't explain db size
Date
Msg-id CAEW0--hOGMx-msVkPbeQjFE5c_GFf_VQmTFXpRHcoGLqDjkZBw@mail.gmail.com
Whole thread Raw
In response to Re: Can't explain db size  (Matteo Grolla <matteo.grolla@gmail.com>)
Responses Re: Can't explain db size
List pgsql-performance
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.grolla@gmail.com>:
Thanks Andreas,
     Il try

2015-12-15 11:07 GMT+01:00 Andreas Kretschmer <akretschmer@spamfence.net>:
Matteo Grolla <matteo.grolla@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


pgsql-performance by date:

Previous
From: Mathieu VINCENT
Date:
Subject: Re: Estimation row error
Next
From: Tom Lane
Date:
Subject: Re: Selectivity for lopsided foreign key columns