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 |