Re: PITR, checkpoint, and local relations
От | J. R. Nield |
---|---|
Тема | Re: PITR, checkpoint, and local relations |
Дата | |
Msg-id | 1028296125.19924.252.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: PITR, checkpoint, and local relations (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PITR, checkpoint, and local relations
|
Список | 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@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
В списке pgsql-hackers по дате отправления: