> > More generally, I'm doubtful that the approach of reading data from WAL > > as proposed here is a very good idea. It seems better to "just" dump the > > entire 2pc state into *one* file at checkpoint time. > > > > I think you misunderstand the proposed approach. This isn't just to do > with reading things back at checkpoint.
Sure, the main purpose is not to write 2pc state files in the common path - or is that not the main purpose?
Yes, that is the main purpose, but that's not what you were talking about.
Currently, the patch reuses all of the code related to reading/write state files, so it is the minimal patch that can implement the important things for performance. The current patch succeeds in its goal to improve performance, so I personally see no further need for code churn.
As you suggest, we could also completely redesign the state file mechanism and/or put it in WAL at checkpoint. That's all very nice but is much more code and doesn't anything more for performance, since the current mainline path writes ZERO files at checkpoint. If you want that for some other reason or refactoring, I won't stop you, but its a separate patch for a separate purpose.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
