From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Wildpaner <mike(at)rainbow(dot)studorg(dot)tuwien(dot)ac(dot)at>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 'COPY ... FROM' inserts to btree, blocks on buffer |
Date: | 2005-01-03 22:47:12 |
Message-ID: | 1104792431.15879.4.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2005-01-03 at 17:14, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2005-01-03 22:55:42 | Re: [HACKERS] Bgwriter behavior |
Previous Message | Kris Jurka | 2005-01-03 22:33:21 | Re: Implementing RESET CONNECTION ... |