From: | "J(dot) R(dot) Nield" <jrnield(at)usol(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Richard Tucker <richt(at)multera(dot)com>, PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PITR, checkpoint, and local relations |
Date: | 2002-08-02 13:48:40 |
Message-ID: | 1028296125.19924.252.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)usol(dot)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(at)usol(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | cbbrowne | 2002-08-02 13:55:07 | Third Manifesto |
Previous Message | Sergio A. Kessler | 2002-08-02 13:38:03 | Re: []performance issues |