Re: Proposal of PITR performance improvement for 8.4.
От | Gregory Stark |
---|---|
Тема | Re: Proposal of PITR performance improvement for 8.4. |
Дата | |
Msg-id | 877i7sbsqc.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Proposal of PITR performance improvement for 8.4. (Simon Riggs <simon@2ndQuadrant.com>) |
Список | 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 по дате отправления: