Michael Paquier writes:
> After making a lot of tests, state file size is not more than 600B.
> In some cases, it reached a maximum of size of 712B and I used such
> transactions in my tests.
I can only say that that demonstrates you didn't test very many cases.
It is trivial to generate enormous
After making a lot of tests, state file size is not more than 600B.
In some cases, it reached a maximum of size of 712B and I used such
transactions in my tests.
> I think setting the size parameter for this would be a frightfully
> difficult problem; the fact that average installations wouldn't u
Heikki Linnakangas 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
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 t
Robert Haas writes:
> On Sat, Aug 8, 2009 at 9:31 AM, Heikki
> Linnakangas 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
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Quite aside from that, the fixed size of shared memory makes this seem
>> pretty impractical.
> Most state files are small. If one doesn't fit in the area reserved for
> this, it's written to disk as usual. It's just an optimization.
What evidence
On Sat, Aug 8, 2009 at 9:31 AM, Heikki
Linnakangas wrote:
> Tom Lane wrote:
>> Michael Paquier writes:
>>> Based on an idea of Heikki Linnakangas, here is a patch in order to improve
>>> 2PC
>>> by sending the state files of prepared transactions to shared memory instead
>>> of disk.
>>
>> I don't
Tom Lane wrote:
> Michael Paquier writes:
>> Based on an idea of Heikki Linnakangas, here is a patch in order to improve
>> 2PC
>> by sending the state files of prepared transactions to shared memory instead
>> of disk.
>
> I don't understand how this can possibly work. The entire point of
> 2PC
Michael Paquier writes:
> Based on an idea of Heikki Linnakangas, here is a patch in order to improve
> 2PC
> by sending the state files of prepared transactions to shared memory instead
> of disk.
I don't understand how this can possibly work. The entire point of
2PC is that the state file is g
