| From: | Csaba Nagy <nagy(at)ecircle-ag(dot)com> |
|---|---|
| To: | Rod Taylor <rod(dot)taylor(at)gmail(dot)com> |
| Cc: | "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Chad Wagner <chad(dot)wagner(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, RPK <rohitprakash123(at)indiatimes(dot)com>, postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: New feature request: FlashBack Query |
| Date: | 2007-02-21 09:17:37 |
| Message-ID: | 1172049456.3101.335.camel@coppola.muc.ecircle.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2007-02-21 10:03:17 | Re: msvc failure in largeobject regression test |
| Previous Message | Tom Lane | 2007-02-21 05:49:11 | Re: tsearch in core patch, for inclusion |