Re: [HACKERS] Incrementally Updated Backup
От
Jim C. Nasby
Тема
Re: [HACKERS] Incrementally Updated Backup
Дата
Msg-id
20060920220728.GF28987@nasby.net
Ответ на
Re: [HACKERS] Incrementally Updated Backup (Tom Lane)
Список
Дерево обсуждения
Incrementally Updated Backup Simon Riggs <simon@2ndquadrant.com>
Re: Incrementally Updated Backup Bruce Momjian <bruce@momjian.us>
Re: [HACKERS] Incrementally Updated Backup Heikki Linnakangas <heikki@enterprisedb.com>
Re: [HACKERS] Incrementally Updated Backup Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Incrementally Updated Backup Simon Riggs <simon@2ndquadrant.com>
Re: [HACKERS] Incrementally Updated Backup "Jim C. Nasby" <jim@nasby.net>
Re: [HACKERS] Incrementally Updated Backup Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Incrementally Updated Backup "Jim C. Nasby" <jim@nasby.net>
Re: [HACKERS] Incrementally Updated Backup Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Incrementally Updated Backup "Jim C. Nasby" <jim@nasby.net>
Re: [HACKERS] Incrementally Updated Backup Csaba Nagy <nagy@ecircle-ag.com>
Re: [HACKERS] Incrementally Updated Backup Bruce Momjian <bruce@momjian.us>
Re: [HACKERS] Incrementally Updated Backup Bruce Momjian <bruce@momjian.us>
On Wed, Sep 20, 2006 at 05:50:48PM -0400, Tom Lane wrote: > "Jim C. Nasby" writes: > > My thought is that in many envoronments it would take much beefier > > hardware to support N postmasters running simultaneously than to cycle > > through them periodically bringing the backups up-to-date. > > How you figure that? The cycling approach will require more total I/O > due to extra page re-reads ... particularly if it's built on a patch > like this one that abandons work-in-progress at arbitrary points. > > A postmaster running WAL replay does not require all that much in the > way of CPU resources. It is going to need I/O comparable to the gross > I/O load of its master, but cycling isn't going to reduce that at all. True, but running several dozen instances on a single machine will require a lot more memory (or, conversely, each individual database gets a lot less memory to use). Of course, this is all hand-waving right now... it'd be interesting to see which approach was actually better. -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
В списке pgsql-patches по дате отправления