Re: Proposal of PITR performance improvement for 8.4. - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Proposal of PITR performance improvement for 8.4.
Date
Msg-id 877i7sbsqc.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Proposal of PITR performance improvement for 8.4.  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:

> On Tue, 2008-10-28 at 12:34 +0000, Gregory Stark wrote:
>> Simon Riggs <simon@2ndQuadrant.com> writes:
>> 
>> I've never liked it -- I
>> always hated that in Oracle and thought it was a terrible kludge.
>
> But now... If you have a better way, great, but that doesn't make
> perfectly workable and fairly simple userspace solutions into kludges.
> That's just an emotive description of your preference.

I won't dispute that calling it a kludge is a personal emotional reaction.

I do think it's *far* from simple though. We would have to manage a variable
number of worker processes, which is a fair amount of code right off the bat.

But the real complexity I fear is in managing the work queue. We would have
yet another fixed size shared memory data structure to configure and a lot of
locking and memory contention on it. 

Keep in mind that potentially every backend process will by trying to enqueue
hundreds of blocks and you'll have dozens (or even hundreds) of worker
processes trying to dequeue blocks. Worst of all, you'll (hopefully) have
someone trying to sort the blocks too which would make it basically impossible
to do anything to minimize the contention.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training!
 


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Updating FSM on recovery
Next
From: Tom Lane
Date:
Subject: Re: Updating FSM on recovery