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@xxxxxxxxxxxxx> schrieb: >Jeff Janes <jeff.janes@xxxxxxxxx> writes: >> On 7/12/11, lars <lhofhansl@xxxxxxxxx> 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@xxxxxxxxxxxxxx) >To make changes to your subscription: >http://www.postgresql.org/mailpref/pgsql-performance -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
