Robert Haas <robertmh...@gmail.com> writes: > On Sat, Aug 8, 2009 at 9:31 AM, Heikki > Linnakangas<heikki.linnakan...@enterprisedb.com> wrote: >> I'm a bit disappointed by the performance gains. I would've expected >> more, given a decent battery-backed-up cache to buffer the WAL fsyncs.
> It doesn't seem that surprising to me that a write to shared memory > and a write to an un-fsync'd file would be about the same speed. I just had a second thought about this. The idea is to avoid writing the separate 2PC state file until/unless it has to be checkpointed. (And, per the comments for CheckPointTwoPhase, that is an uncommon case --- especially now with our time-extended checkpoints.) 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers