> Do 97% of transactions commit because Oracle has slow rollbacks and
> developers are working around that performance issue, or because they
> really commit?
>
> I have watched several developers that would prefer to issue numerous
> selects to verify things like foreign keys in the application in
> order to avoid a rollback.
Most of the code we have will not afford a rollback because it can be
part of a much bigger transaction which would have much higher
performance penalty if retried than a simple rollback. And you know that
in postgres you can't roll back just the last insert, you will crash the
whole transaction with it... and it's simply a performance bottleneck to
retry in a high contention scenario (which is usually so in our case).
So I would say we don't avoid rollbacks because of the cost of the
rollback, but because of the cost of the retry...
Cheers,
Csaba.
