Tom Lane wrote:
> What if PREPARE simply didn't write the 2PC file at all, except into WAL?
> Then, make CheckPointTwoPhase write the 2PC file for any still-live
> GXACT, by means of reaching into the WAL and pulling the data out.
> All it would need for that is the LSN of the WAL record, which I think
> the GXACT has already. (It might have the end location rather than
> the start, but in any case we could store both.) Similarly, COMMIT
> PREPARED could be taught to pull the data from WAL instead of a 2PC
> file, in the typical case where the file didn't exist yet. I think
> there might be some synchronization issues against checkpoints --- you
> couldn't recycle WAL until you were sure there was no COMMIT PREPARED
> pulling from it. But it seems possibly workable, and there's no tuning
> knob needed.
Interesting idea, might be worth performance testing. Peeking into the
WAL files during normal operation feels naughty, but it should work.
However, if the bottleneck is the WAL fsyncs, I doubt it's any faster
than Michael's current patch.
Actually, it would be interesting to performance test a stripped down
broken implementation that doesn't write the state files anywhere but
WAL, PREPARE releases all locks like regular COMMIT does, and COMMIT
PREPARED just writes the commit record and fsyncs. That would give an
upper bound on how much gain any of these patches can have. If that's
not much, we can throw in the towel.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
