"Jonah H. Harris" <[EMAIL PROTECTED]> writes:

> On 2/20/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
>> It's more like Oracle is optimized for data that's committed
>> long in the past and we're optimized for data that's
>> been recently updated.
> 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... 

Sure, and if it was committed long in the past then you can use it. If it's
committed recently then you'll have to start looking up rollback data instead.

The rest of your post seems to all be predicated on the idea that if data is
committed then that's all you'll need to look at. But that's missing precisely
the point of what I was saying:

>> In a sense then it's the opposite of what we usually say. Oracle is optimized
>> for mostly static data. Postgres is optimized for changing data.

By "changing data" I meant "data in flux", not the action of making changes to
the data. 

Looking at data in flux in Oracle -- even other data that's unchanged but
lives on the same page as some record that's in flux -- will require you to
look up rollback data and possibly even have to follow many pages of chained
rollback data. Looking at data in Postgres has no additional overhead when
it's data in flux versus old static data.

  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to