RE: OID Perfomance - Object-Relational databases

I'm a little concerned about all this, because my understanding is that what
makes an object database so fast is its ability to directly reference
tuples, so that traversing relationships becomes like traversing pointers.

The achilles heel of relational databases is the inability to do exactly
that. Postgres has a sufficiently extended query language that traversing
relationships in this manner can be dealt with, and doing this from a decent
OO development tool should remove the general pain of dealing with OIDs.

Or is there something that I'm missing? What I expect from an OR database
is the speed of an object database (which seems to come mainly from it's OID
mechanism), with the manipulative power of a traditional relational
database, and then a whole truckload of extras, like rules, procedures, an
OR query language, etc. So, effectively, it's more than the sum of ODB and
RDB.

In order to promote Postgres in the environment that I'm in now, I need it
to attain at least the same order of speed as an ODB. Are there any
benchmarks anywhere that I can quote against ODBs? I need some help here,
because the general feeling that I'm up against is that we should be using
either ODB or RDB, not ORDB as it is the worst of both worlds, being slow,
not completely object-orientated, and not as flexible as ODBs, and less
robust than RDBs, because of the object extensions. I need some ammo.

MikeA

>> -----Original Message-----
>> From: Josh Berkus [mailto:josh(at)agliodbs(dot)com]
>> Sent: 04 October 2000 05:11
>> To: pgsql-sql(at)postgresql(dot)org
>> Cc: pgman(at)candle(dot)pha(dot)pa(dot)us
>> Subject: Re: [SQL] OID Perfomance - Object-Relational databases
>>
>>
>> Tom,
>>
>> > The trouble with pg_dump -o is that after reload, the OID
>> > generator
>> > will be set to max(any OID in the dumped data). So a
>> > dump & reload
>> > doesn't do anything to postpone OID-wraparound Ragnarok.
>> >
>> > As for the likelihood of overflow, figure 4G / tuple
>> > creation rate
>> > for your installation (not database, but whole
>> > installation controlled
>> > by one postmaster). Unless your installation has just
>> > one active
>> > table, per-table sequence values look like a better bet.
>>
>> Somebody (urgently) needs to tell all of the above to Bruce
>> Momjian (I've cc'd him); his book-in-the-making points up
>> OID's as a convenient and universal way to identify and link
>> tuples (chapter 7) and doen't mention these problems. Who
>> can I bug about how useless the above makes OID's?
>>
>> Thanks for the warning, and thanks Michael for the
>> suggestion; I'll use it and send you all back notes on how
>> it affects performance.
>>
>> -Josh
>>
>>
>>
>>
>>