Claudio Freire wrote: > On Tue, Feb 7, 2012 at 4:12 PM, Ofer Israeli <oferi@xxxxxxxxxxxxxx> > wrote: >> Something specific that you refer to in autovacuum's non-perfection, >> that is, what types of issues are you aware of? > > I refer to its criteria for when to perform vacuum/analyze. > Especially analyze. It usually fails to detect the requirement to > analyze a table - sometimes value distributions change without > triggering an autoanalyze. It's expected, as the autoanalyze works on > number of tuples updates/inserted relative to table size, which is > too generic to catch business-specific conditions. > > As everything, it depends on your business. The usage pattern, the > kinds of updates performed, how data varies in time... but in > essence, I've found that forcing a periodic vacuum/analyze of tables > beyond what autovacuum does improves stability. You know a lot more > about the business and access/update patterns than autovacuum, so you > can schedule them where they are needed and autovacuum wouldn't. > >> As for the I/O - this is indeed true that it can generate much >> activity, but the way I see it, if you run performance tests and the >> tests succeed in all parameters even with heavy I/O, then you are >> good to go. That is, I don't mind the server doing lots of I/O as >> long as it's not causing lags in processing the messages that it >> handles. > > If you don't mind the I/O, by all means, crank it up. Thanks for the lep Claudio. We're looking into both these options. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
