Re: [PATCH] 2PC state files on shared memory
От | Tom Lane |
---|---|
Тема | Re: [PATCH] 2PC state files on shared memory |
Дата | |
Msg-id | 28134.1249761279@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCH] 2PC state files on shared memory (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-hackers |
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: > Tom Lane wrote: >> What if PREPARE simply didn't write the 2PC file at all, except into WAL? > 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. This isn't about faster, it's about not requiring users to estimate a suitable size for a shared-memory arena. > 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. Good idea --- although I would think that the performance of 2PC would be pretty context-dependent anyway. What load would you test under? regards, tom lane
В списке pgsql-hackers по дате отправления: