On 2/20/07, Hannu Krosing <[EMAIL PROTECTED]> wrote:
He probably meant longer transactions and several versions visible to
Yes, he may have... but I was responding to the statements he made.
> but why shouldn't that be a bit slower, it isn't common practice anyway.
Not for pure OLAP, at least when you have fairly fast transactions. But
it can slow things down when you have some hotspot tables.
True, but hotspots are hotspots and no matter what caused them or
where they are, they slow down performance in one area or another.
Limiting hotspots is generally an application-level design decision
> Same with rollbacks... why
> should they optimize for them when 97% of transactions commit?
Or other way around, - you should write code, where most transactions
That's what I said, Oracle shouldn't optimize for rollbacks when most
Hmm. How can it check visibility at block level and at the same time do
in-place updates on single tuples ?
In most cases, the block-level SCN determines transaction-level
visibility. Now, row locks can exist within that page, but they don't
determine visibility... they determine the UNDO location which
contains the data required to rebuild a read-consistent version of the
My proposal of keeping visibility info in a separate heap would help to
get similar results, that is mostly 1 check per page. That would also
cover much of the index lookup cases below.
I don't think we will ever move to rollback segments, but for some
use-cases moving visibility to a separate heap could make sense.
And if we want to bring back time travel (see another thread about
"Flashback Queries"), then we may end up implementing the original
postgresql's design spec and make VACUUM spihon dead tuples over to
archive relations, which already starts looking a little like rollback
segments, only for other purposes :)
Using a system extensively can also create blind spots about some of the
systems (mis)features. One learns to avoid doing some things without
consciously knowing about it.
I've used 'em all and can certainly name issues with Oracle. However,
we're discussing improving PostgreSQL, I was responding to Greg's
statements, and I don't see the need to bring up unrelated Oracle
implementation details which will just lead to a general anti-Oracle
To get a really meaningful discussion we should involve someone who has
*designed* them, not merely used them .
True. My comment is more along the lines of uninformed discussion
which leads to Oracle-bashing. Those who have at least used and
administered Oracle in production tend to understand Oracle's design
decisions and related issues better than those who have just heard of
I live in the real world and can admit certain failures of any
database system regardless of which I prefer. No single database is
best for every task. I just didn't want the discussion going where it
normally goes, to being one of, "we're right and they're wrong".
Can we move offline or to another thread if we want to continue
discussing Oracle-specifics; otherwise... let's focus on
flashback-like functionality in this thread.
Jonah H. Harris, Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 3rd Floor | [EMAIL PROTECTED]
Iselin, New Jersey 08830 | http://www.enterprisedb.com/
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend