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:[EMAIL PROTECTED]]
>> Sent: 04 October 2000 05:11
>> To: [EMAIL PROTECTED]
>> Cc: [EMAIL PROTECTED]
>> 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
>>
>>
>>
>>
>>
