Skip site navigation (1) Skip section navigation (2)

Re: Inserts or Updates

From: Ofer Israeli <oferi(at)checkpoint(dot)com>
To: Claudio Freire <klaussfreire(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Inserts or Updates
Date: 2012-02-07 19:12:01
Message-ID: 217DDBC2BB1E394CA9E7446337CBDEF20102C056BE8E@il-ex01.ad.checkpoint.com (view raw or flat)
Thread:
Lists: pgsql-performance
>> You mean running a VACUUM statement manually?  I would basically try to
>> avoid such a situation as the way I see it, the database should be
>> configured in such a manner that it will be able to handle the load at 
>> any given moment and so I wouldn't want to manually intervene here.  If 
>> you think differently, I'll be happy to stand corrected.
> 
> I do think differently.
> 
> Autovacuum isn't perfect, and you shouldn't make it too aggressive
> since it does generate a lot of I/O activity. If you can pick a time
> where it will be able to run without interfering too much, running
> vacuum "manually" (where manually could easily be a cron task, ie,
> automatically but coming from outside the database software itself),
> you'll be able to dial down autovacuum and have more predictable load
> overall.
> 


Something specific that you refer to in autovacuum's non-perfection, that is, what types of issues are you aware of?

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.


Thanks,
Ofer


In response to

Responses

pgsql-performance by date

Next:From: Claudio FreireDate: 2012-02-07 19:20:46
Subject: Re: Inserts or Updates
Previous:From: Gudmundur JohannessonDate: 2012-02-07 17:59:33
Subject: Re: Index with all necessary columns - Postgres vs MSSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group