Re: PITR, checkpoint, and local relations

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

In response to

Responses

Browse pgsql-hackers by date

  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