To: "Mauro N. Infantino" <mauroi@digbang.com>
cc: pgsql-performance@postgresql.org
Subject: Re: Very specific server situation 
In-reply-to: <01bc01c788f2$ef6475b0$ec01010a@intranet.db> 
References: <01bc01c788f2$ef6475b0$ec01010a@intranet.db>
Comments: In-reply-to "Mauro N. Infantino" <mauroi@digbang.com>
	message dated "Fri, 27 Apr 2007 14:38:57 -0300"
Date: Fri, 27 Apr 2007 18:51:36 -0400
Message-ID: <6665.1177714296@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Mauro N. Infantino" <mauroi@digbang.com> writes:
> What we basically have is a site where each user has a box with links to
> other randomly selected users. Whenever a box from a user is shown, a SPs is
> executed: a credit is added to that user and a credit is substracted from
> the accounts of the shown links. Accounts with no credits do not have to be
> listed. So, we've lots (LOTS) of users querying and updating the same table.

Have you checked to make sure the query plans are reasonable?  Have you
checked that autovacuum is running often enough?  (You might want to try
contrib/pgstattuple to see how much dead space there is in your
heavily-updated tables.)  Also, on a high-update workload it is
absolutely critical to boost checkpoint_segments far enough that you are
not doing checkpoints oftener than maybe once every five minutes.

If the performance problems seem "bursty" then you may also need to look
at adjusting bgwriter and/or vacuum cost delay parameters to smooth out
the I/O load.

			regards, tom lane