Re: 'COPY ... FROM' inserts to btree, blocks on buffer - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: 'COPY ... FROM' inserts to btree, blocks on buffer
Date
Msg-id 1104792431.15879.4.camel@localhost.localdomain
Whole thread Raw
In response to Re: 'COPY ... FROM' inserts to btree, blocks on buffer writeout  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 2005-01-03 at 17:14, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > The situation where another backend requests the block immediately
> > before the I/O is fairly common AFAICS, especially since
> > StrategyGetBuffer ignores the BM_DIRTY flag in selecting victims.
> 
> How do you figure that?  StrategyGetBuffer won't return the same buffer
> again (because dirty or not, it'll be pinned by the time anyone else
> gets to run StrategyGetBuffer).  The case we are interested in is where
> someone suddenly wants the original page again --- that is, a page that
> was just about to fall off the back end of the freelist is wanted again.
> I don't see that that case is common, especially not with a reasonably
> large shared_buffer setting, and most especially not when the bgwriter
> is doing its job and keeping the back end of the freelist clean.

Yes, what I was effectively arguing for was to tune for the case where
shared_buffers is still at the default...which is of course fairly
pointless, since the way to tune is just to increase shared_buffers.

...Fully agree with your original suggestion now.

-- 
Best Regards, Simon Riggs



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [ANNOUNCE] PostgreSQL 8.0.0 Release Candidate 3
Next
From: Simon Riggs
Date:
Subject: Re: [PATCHES] Bgwriter behavior