| From: | Rod Taylor <rod(dot)taylor(at)gmail(dot)com> |
|---|---|
| To: | "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com> |
| Cc: | "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>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: New feature request: FlashBack Query |
| Date: | 2007-02-20 15:42:28 |
| Message-ID: | 74F771E7-C2B3-41F8-946A-AA7E83444EE3@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> Wrong. When Oracle says it's committed, it's committed. No
> difference between when, where, and how. In Oracle, the committed
> version is *always* the first presented to the user... it takes time
> to go back and look at older versions; but why shouldn't that be a bit
> slower, it isn't common practice anyway. Same with rollbacks... why
> should they optimize for them when 97% of transactions commit?
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.
Anyway, I don't have experience with big Oracle applications but I'm
not so sure that 97% of transactions would commit if rollbacks were
cheaper.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | mark | 2007-02-20 15:47:43 | Re: [HACKERS] HOT WIP Patch - version 2 |
| Previous Message | Jonah H. Harris | 2007-02-20 15:20:04 | Re: New feature request: FlashBack Query |