From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Inserts or Updates |
Date: | 2012-02-07 19:20:46 |
Message-ID: | CAGTBQpaLnwzT-W0jxsgyX7GtHaChv9ifWwpKzxYkaasj8Au2pQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Feb 7, 2012 at 4:12 PM, Ofer Israeli <oferi(at)checkpoint(dot)com> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2012-02-07 19:26:40 | Re: Index with all necessary columns - Postgres vs MSSQL |
Previous Message | Ofer Israeli | 2012-02-07 19:12:01 | Re: Inserts or Updates |