Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum
От | Andres Freund |
---|---|
Тема | Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum |
Дата | |
Msg-id | 200912061751.20080.andres@anarazel.de обсуждение исходный текст |
Ответ на | Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum (Andreas Thiel <andreas.thiel@u-blox.com>) |
Список | 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 по дате отправления: