Re: 2-phase commit

Martha Stewart called it a Good Thing whenDCorbit(at)connx(dot)com ("Dann Corbit")wrote:
>> I can't see a grave overhead from this comparison.
>
> 2PC is absolutely essential when you have to have both parts of the
> transaction complete for a logical unit of work. For a project that
> needs it, if you don't have it you will be forced to go to another
> tool, or perform lots of custom programming to work around it.
>
> If you have 2PC and it is ten times slower than without it, you will
> still need it for projects requiring that capability.

Just so.

I would be completely unsurprised if an attempt to use 2PC to support
generalized "multimaster replication" would involve 10-fold slowdowns
as compared to having all the activity take place on one database.

Which would imply that 2PC is not a tool that may be appropriately
used to naively do replication. But that should not come as any grand
surprise.

To each tool the right job, and to each job the right tool...

There seems to be enough room for there to be evidence both of 2PC
being useful for improving performance, and for it to cut
performance:

- TPC benchmarks often specify the inclusion of Tuxedo as a
component; the combination of vendors would surely NOT put it
on the list if it were not an aid to performance;

- There is also indication that there can be a cost, notably in the
form of the concerns of deadlock, but it should also be obvious
that slow network links would lead to _hideous_ increases in
latency.

As you say, even if there is a substantial cost, it's still worthwhile
if a project needs it.

> Now, a good model to start with is a very good idea. So some
> discussion and analysis is a good thing. From the looks of it,
> Satoshi Nagayasu has done a very good job. Having a functional 2PC
> would be a huge feather in the cap of PostgreSQL.

It would seem so. I look forward to seeing how this progresses.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','acm.org').
http://cbbrowne.com/info/linuxdistributions.html
"XFS might (or might not) come out before the year 3000. As far as
kernel patches go, SGI are brilliant. As far as graphics, especially
OpenGL, go, SGI is untouchable. As far as filing systems go, a
concussed doormouse in a tarpit would move faster." -- jd on Slashdot