Ok. This is what I wanted to hear, but I had assumed someone decided to
put it in for a reason, and I wasn't going to submit a patch to pull-out
the local buffer manager without clearing it first.
The main area where it seems to get heavy use is during index builds,
and for 'CREATE TABLE AS SELECT...'.
So I will remove the local buffer manager as part of the PITR patch,
unless there is further objection.
On Fri, 2002-08-02 at 00:49, Tom Lane wrote:
> "J. R. Nield" <jrnield@usol.com> writes:
> > I am working on a way to do this with a signal, using holdoffs around
> > calls into the storage-manager and VFS layers to prevent re-entrant
> > calls. The local buffer manager is simple enough that it should be
> > possible to flush them from within a signal handler at most times, but
> > the VFS and storage manager are not safe to re-enter from a handler.
>
> > Does this sound like a good idea?
>
> No. What happened to "simple"?
>
> Before I'd accept anything like that, I'd rip out the local buffer
> manager and just do everything in the shared manager. I've never
> seen any proof that the local manager buys any noticeable performance
> gain anyway ... how many people really do anything much with a table
> during its first transaction of existence?
>
> regards, tom lane
>
--
J. R. Nield
jrnield@usol.com
