Re: 'COPY ... FROM' inserts to btree, blocks on buffer
От | Simon Riggs |
---|---|
Тема | Re: 'COPY ... FROM' inserts to btree, blocks on buffer |
Дата | |
Msg-id | 1104792431.15879.4.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: 'COPY ... FROM' inserts to btree, blocks on buffer writeout (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: