> -----Original Message-----
> From: Satoshi Nagayasu [mailto:pgsql@snaga.org] 
> Sent: Friday, October 10, 2003 12:26 PM
> To: Andrew Sullivan
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] 2-phase commit
> 
> Andrew Sullivan <andrew@libertyrms.info> wrote:
> > On Fri, Oct 10, 2003 at 09:46:35AM +0900, Tatsuo Ishii wrote:
> > > Satoshi, the only guy who made a trial implementation of 2PC for 
> > > PostgreSQL, has already showed that 2PC is not that slow.
> > 
> > If someone has a fast implementation, so much the better.  I'm not 
> > opposed to fast implementations!
> 
> The pgbench results of my experimental 2PC implementation
> and plain postgresql are available.
> 
> PostgreSQL 7.3
>   http://snaga.org/pgsql/pgbench/pgbench-REL7_3.log
> 
> Experimental 2PC in PostgreSQL 7.3
>   http://snaga.org/pgsql/pgbench/pgbench-TPC0_0_2.log
> 
> 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.

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.

IMO-YMMV

Fri, 10 Oct 2003 15:28:05 -0700
"Dann Corbit" <DCorbit@connx.com>
Re: 2-phase commit
Martha Stewart called it a Good Thing whenDCorbit@connx.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

Fri, 10 Oct 2003 22:54:31 -0400
Christopher Browne <cbbrowne@acm.org>
Re: 2-phase commit