> Le 6 oct. 2017 à 23:44, Alvaro Herrera <alvhe...@alvh.no-ip.org> a écrit : > > Michael Paquier wrote: > >> The only sane method for Postgres is really to scan the >> page header LSNs, and of course you already know that. > > I hope the idea is not to have to scan every single page in the > database, because that would be too slow. It should be possible to > build this so that a single summary LSN is kept for a largish group of > pages, allowing large portions of the database to be skipped from even > being read if they are known not to contain any page newer than the > previous backup.
That’s actually what pg_rman is doing for what it calls incremental backups (perhaps that would be differential backup in PG terminology?), and the performance is bad as you can imagine. We could have a dedicated LSN map to do such things with 4 bytes per page. I am still not convinced that this much facility and the potential bug risks are worth it though, Postgres already knows about differential backups if you shape it as a delta of WAL segments. I think that, in order to find a LSN map more convincing, we should find first other use cases where it could become useful. Some use cases may pop up with VACUUM, but I have not studied the question hard enough... -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
