RE: OID Perfomance - Object-Relational databases

<p><font size="2">I'm a little concerned about all this, because my understanding is that what makes an object database
sofast is its ability to directly reference tuples, so that traversing relationships becomes like traversing
pointers.</font><p><fontsize="2">The achilles heel of relational databases is the inability to do exactly that. 
Postgreshas a sufficiently extended query language that traversing relationships in this manner can be dealt with, and
doingthis from a decent OO development tool should remove the general pain of dealing with OIDs.</font><p><font
size="2">Oris there something that I'm missing?  What I expect from an OR database is the speed of an object database
(whichseems to come mainly from it's OID mechanism), with the manipulative power of a traditional relational database,
andthen a whole truckload of extras, like rules, procedures, an OR query language, etc.  So, effectively, it's more
thanthe sum of ODB and RDB.</font><p><font size="2">In order to promote Postgres in the environment that I'm in now, I
needit to attain at least the same order of speed as an ODB.  Are there any benchmarks anywhere that I can quote
againstODBs?  I need some help here, because the general feeling that I'm up against is that we should be using either
ODBor RDB, not ORDB as it is the worst of both worlds, being slow, not completely object-orientated, and not as
flexibleas ODBs, and less robust than RDBs, because of the object extensions.  I need some ammo.</font><p><font
size="2">MikeA</font><br/><br /><br /><p><font size="2">>>   -----Original Message-----</font><br /><font
size="2">>>  From: Josh Berkus [<a href="mailto:josh@agliodbs.com">mailto:josh@agliodbs.com</a>]</font><br
/><fontsize="2">>>   Sent: 04 October 2000 05:11</font><br /><font size="2">>>   To:
pgsql-sql@postgresql.org</font><br/><font size="2">>>   Cc: pgman@candle.pha.pa.us</font><br /><font
size="2">>>  Subject: Re: [SQL] OID Perfomance - Object-Relational databases </font><br /><font
size="2">>>  </font><br /><font size="2">>>   </font><br /><font size="2">>>   Tom,</font><br /><font
size="2">>>  </font><br /><font size="2">>>   > The trouble with pg_dump -o is that after reload, the
OID</font><br/><font size="2">>>   > generator</font><br /><font size="2">>>   > will be set to
max(anyOID in the dumped data).  So a</font><br /><font size="2">>>   > dump & reload</font><br /><font
size="2">>>  > doesn't do anything to postpone OID-wraparound Ragnarok.</font><br /><font size="2">>>  
></font><br /><font size="2">>>   > As for the likelihood of overflow, figure 4G / tuple</font><br /><font
size="2">>>  > creation rate</font><br /><font size="2">>>   > for your installation (not database,
butwhole</font><br /><font size="2">>>   > installation controlled</font><br /><font size="2">>>   >
byone postmaster).  Unless your installation has just</font><br /><font size="2">>>   > one active</font><br
/><fontsize="2">>>   > table, per-table sequence values look like a better bet.</font><br /><font
size="2">>>  </font><br /><font size="2">>>   Somebody (urgently) needs to tell all of the above to
Bruce</font><br/><font size="2">>>   Momjian (I've cc'd him); his book-in-the-making points up</font><br /><font
size="2">>>  OID's as a convenient and universal way to identify and link</font><br /><font size="2">>>  
tuples(chapter 7) and doen't mention these problems.  Who</font><br /><font size="2">>>   can I bug about how
uselessthe above makes OID's?</font><br /><font size="2">>>   </font><br /><font size="2">>>   Thanks for
thewarning, and thanks Michael for the</font><br /><font size="2">>>   suggestion; I'll use it and send you all
backnotes on how</font><br /><font size="2">>>   it affects performance.</font><br /><font size="2">>>  
</font><br/><font size="2">>>   -Josh</font><br /><font size="2">>>   </font><br /><font
size="2">>>  </font><br /><font size="2">>>   </font><br /><font size="2">>>   </font><br /><font
size="2">>>  </font>