On 12/20/2017 09:29 PM, Pavel Stehule wrote: > > > 2017-12-20 21:18 GMT+01:00 Robert Haas <robertmh...@gmail.com > <mailto:robertmh...@gmail.com>>: > > On Wed, Dec 20, 2017 at 3:15 PM, Pavel Stehule > <pavel.steh...@gmail.com <mailto:pavel.steh...@gmail.com>> wrote: > >> > So I'm somewhat hesitant to proclaim option 5 as the clear winner, > here. > >> > >> I agree. I think (4) is better. > > > > Can depends on load? For smaller intensive updated databases the 5 can > be > > optimal, for large less updated databases the 4 can be better. > > It seems to me that the difference is that (4) tracks which pages have > changed in the background, and (5) does it in the foreground. Why > would we want the latter? > > > Isn't more effective hold this info in Postgres than in backup sw? > Then any backup sw can use this implementation. >
I don't think it means it can't be implemented in Postgres, but does it need to be done in backend? For example, it might be a command-line tool similar to pg_waldump, which processes WAL segments and outputs list of modified blocks, possibly with the matching LSN. Or perhaps something like pg_receivewal, doing that in streaming mode. This part of the solution can still be part of PostgreSQL codebase, and the rest has to be part of backup solution anyway. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
