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" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
