Re: Blocking excessively in FOR UPDATE

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Blocking excessively in FOR UPDATE
Date: 2011-11-04 16:48:51
Message-ID: CAGTBQpZHpTbvic4M=+mVUphoJuLTwzDVNM7NQjO_10oNOEwiXg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, Nov 4, 2011 at 1:26 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> As already pointed out, SELECT FOR UPDATE will require a disk write
> of the tuple(s) read.  If these are glutting, increasing
> shared_buffers would tend to make things worse.

I thought shared_buffers improved write caching.
We do tend to write onto the same rows over and over.

> Hopefully you have a BBU RAID controller configured for write-back.
> If not you should.  If you do, another thing which might help is
> increasing the cache on that controller.

Write-back on the RAID is another issue.
The controller is old and has a very small cache, we're already in the
process of securing a replacement.

> Or you could move WAL to a
> separate file system on a separate controller with its own BBU
> write-back cache.

WAL is already on a separate controller and array.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Grittner 2011-11-04 17:07:49 Re: Blocking excessively in FOR UPDATE
Previous Message Kevin Grittner 2011-11-04 16:26:57 Re: Blocking excessively in FOR UPDATE