Re: UPDATEDs slowing SELECTs in a fully cached database

shared_buffers is big enough to hold the entire database, and there is plenty of extra space. (verified with PG_buffercache)
So i don't think that is the reason.

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> schrieb:

>Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
>> On 7/12/11, lars <lhofhansl(at)yahoo(dot)com> wrote:
>>> The fact that a select (maybe a big analytical query we'll run) touching
>>> many rows will update the WAL and wait
>>> (apparently) for that IO to complete is making a fully cached database
>>> far less useful.
>>> I just artificially created this scenario.
>
>> I can't think of any reason that that WAL would have to be flushed
>> synchronously.
>
>Maybe he's running low on shared_buffers? We would have to flush WAL
>before writing a dirty buffer out, so maybe excessive pressure on
>available buffers is part of the issue here.
>
> regards, tom lane
>
>--
>Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-performance