Re: Inserts or Updates - Mailing list pgsql-performance

From Ofer Israeli
Subject Re: Inserts or Updates
Date
Msg-id 217DDBC2BB1E394CA9E7446337CBDEF20102C056BFBC@il-ex01.ad.checkpoint.com
Whole thread Raw
In response to Re: Inserts or Updates  (Claudio Freire <klaussfreire@gmail.com>)
List pgsql-performance
Claudio Freire wrote:
> On Tue, Feb 7, 2012 at 4:12 PM, Ofer Israeli <oferi@checkpoint.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.


Thanks for the lep Claudio.  We're looking into both these options.

pgsql-performance by date:

Previous
From: Rural Hunter
Date:
Subject: Re: index scan forward vs backward = speed difference of 357X slower!
Next
From: Ofer Israeli
Date:
Subject: Re: Inserts or Updates