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 <t...@sss.pgh.pa.us> schrieb: >Jeff Janes <jeff.ja...@gmail.com> writes: >> On 7/12/11, lars <lhofha...@yahoo.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@postgresql.org) >To make changes to your subscription: >http://www.postgresql.org/mailpref/pgsql-performance -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
