Ron Peacetree wrote
> ...and what kind of performance hit we take (and under what
> circumstances) for not having it?
Are you thinking of "two phase commit"?
There is no "performance hit for not having it."
And it does not currently apply to PostgreSQL. Two phase commit is only
needed when updates need to be applied simultaneously on multiple
databases.
That is, you'd have something like:
CREATE DISTRIBUTED TRANSACTION X1; insert into table TBL1 in database ('db1', 'id1', 'auth1') values (1, 2, 100.00,
now());insert into table TBL2 in database ('db2', 'id2', 'auth2') values (1, 3, -100.00, now());
COMMIT DISTRIBUTED TRANSACTION X1;
where the "in database ('db1', 'id1', 'auth1')" part indicates some form
of connection parameters for the database.
There certainly is merit to having two phase commit; it allows
coordinating updates to multiple databases.
The "degradation of performance" that results from not having this is
that you can't have distributed transactions. That's not a "performance
hit;" that's a case of "you can't do distributed transactions."
And distributed transactions are probably /more/ expensive than
nondistributed ones, so it is more readily argued that by not supporting
them, you don't have the problem of performance degrading due to making
use of distributed transactions.
--
output = reverse("gro.gultn@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/nonrdbms.html
Rules of the Evil Overlord #195. "I will not use hostages as bait in a
trap. Unless you're going to use them for negotiation or as human
shields, there's no point in taking them."
<http://www.eviloverlord.com/>
