Hi Steve:
On Wed, Sep 23, 2015 at 7:25 PM, Steve Pritchard
wrote:
> I thought that autovacuum should recover the free space, however I see now
> from the documentation that it doesn't (and that this is deliberate):
> I'll do a VACUUM FULL, which I expect to reduce table_len.
Full is for whe
Tom,
Thanks for the tip about pgstattuple - I hadn't discovered that (and I
hadn't realised that it's bundled in the 9.4.4 distribution).
This is what I get:
SELECT * FROM pgstattuple('observation');
table_len 21,954,740,224
tuple_count 34,373,274
tuple_len 9,307,650,026
Could you please check this after running Vacuum Analyze. I know there may
not be big difference.
As par my analysis this is free space available in table but not free in
respect to server space.
Like table contains 3 type of space.
1 Live row space
2 Dead row space
3 Free space available for tha
Steve Pritchard writes:
> -- Average length of a row in bytes:
> select avg(octet_length(t.*::text)) FROM observation t;
> -- 287 bytes
That measurement technique doesn't have a lot to do with reality,
I'm afraid.
The contrib/pgstattuple module could give you a more reliable idea of
how much spa
I have a large table in Postgres 9.4.4 called 'observation', which is by
far the largest item in the database. When I pg_dump this table the
resulting file is about 9GB. However I've noticed that the pg data
directory uses about 30GB (excluding pg_xlog).
Looking at the space usage:
-- Size of 'wa