Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum - Mailing list pgsql-performance

From Andres Freund
Subject Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum
Date
Msg-id 200912061751.20080.andres@anarazel.de
Whole thread Raw
In response to Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum  (Andreas Thiel <andreas.thiel@u-blox.com>)
List pgsql-performance
Hi Andreas,

Could you please properly quote the email? The way you did it is quite
unreadable because you always have to guess who wrote what.

On Sunday 06 December 2009 17:06:39 Andreas Thiel wrote:
> > I'm going to work on the table size of the largest table (result_orig)
> > itself by eliminating columns, stuffing n Booleans into bit(n)'s,
> > replacing double precision by reals, etc.. By this I should be able to
> > reduce the storage per row to ~1/3 of the bytes currently used.
> That sounds rather ambitous - did you factor in the per row overhead?
> I did now create the new table, I have now 63 instead of 94 bytes/row on
> average. So yes you're right I'm about to hit the bottom of the per row
> overhead.
How did you calculate that? Did you factor in the alignment requirements? The
ddl would be helpfull...

> Btw, have you possibly left over some old prepared transactions or an
> idle in
> transaction connection? Both can lead to sever bloat.
> For the former you can check the system table pg_prepared_xact for the
> latter
> pg_stat_activity.
> Seems no the case, pg_prepared_xact doesn't even exist.
Its pg_prepared_xacts (note the s), sorry my mind played me.

> Where would I find that postmaster output? In syslog? There's nothing
> visible...
Depends on your setup. I have not the slightest clue about centos. If
necessary start postmaster directly.

> > max_fsm_relations = 4194304             # min 100, ~70 bytes each
Have you corrected that value?


Andres

pgsql-performance by date:

Previous
From: Greg Smith
Date:
Subject: Re: performance while importing a very large data set in to database
Next
From: Andres Freund
Date:
Subject: Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum