On Wed, Apr 17, 2019 at 11:57:35AM -0400, Bruce Momjian wrote: > On Tue, Apr 16, 2019 at 06:40:44PM -0400, Robert Haas wrote: > > Yeah, I really hope we don't end up with dueling patches. I want to > > come up with an approach that can be widely-endorsed and then have > > everybody rowing in the same direction. On the other hand, I do think > > that we may support multiple options in certain places which may have > > the kinds of trade-offs that Bruce mentions. For instance, > > identifying changed blocks by scanning the whole cluster and checking > > the LSN of each block has an advantage in that it requires no prior > > setup or extra configuration. Like a sequential scan, it always > > works, and that is an advantage. Of course, for many people, the > > competing advantage of a WAL-scanning approach that can save a lot of > > I/O will appear compelling, but maybe not for everyone. I think > > there's room for two or three approaches there -- not in the sense of > > competing patches, but in the sense of giving users a choice based on > > their needs. > > Well, by having a separate modblock file for each WAL file, you can keep > both WAL and modblock files and use the modblock list to pull pages from > each WAL file, or from the heap/index files, and it can be done in > parallel. Having WAL and modblock files in the same directory makes > retention simpler. > > In fact, you can do an incremental backup just using the modblock files > and the heap/index files, so you don't even need the WAL. > > Also, instead of storing the file name and block number in the modblock > file, using the database oid, relfilenode, and block number (3 int32 > values) should be sufficient.
Would doing it that way constrain the design of new table access methods in some meaningful way? Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate