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.
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 |