On Sat, Oct 7, 2017 at 6:34 AM, Stephen Frost <sfr...@snowman.net> wrote: >> > 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... >> >> The case I've discussed with barman developers is a large database >> (couple dozen of TBs should be enough) where a large fraction (say 95%) >> is read-only but there are many changes to the active part of the data, >> so that WAL is more massive than size of active data. > > Yes, we've seen environments like that also.
I'm pretty sure that those cases are cases where there are many more FPIs than might be expected, due to a lack of locality. (UUID PKs can make the size of WAL balloon, for example.) -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers