On Mon, 6 Aug 2001, mlw wrote:
> Zeugswetter Andreas SB SD wrote:
> >
> > > It seems to me, I guess and others too, that the OID mechanism should
> > be on a
> > > per table basis. That way OIDs are much more likely to be unique, and
> > TRUNCATE
> > > on a table should reset it's OID counter to zero.
> >
> > Seems to me, that this would be no different than a performance improved
> > version
> > of SERIAL.
> > If you really need OID, you imho want the systemid tableid tupleid
> > combo.
> > A lot of people seem to use OID, when they really could use XTID. That
> > is
> > what I wanted to say.
> >
>
> I don't care about having an OID or ROWID, I care that there is a 2^32 limit to
> the current OID strategy and that a quick fix of allowing tables to exist
> without OIDs may break some existing software. I was suggesting the OIDs be
> managed on a "per table" basis as a better solution.
Again, what existing software demands per-table OID field? Isn't it what
primary keys are for?
> In reality, a 32 bit OID, even isolated per table, may be too small.
> Databases are getting HUGE. 40G disk drives are less than $100 bucks,
> in a few months 80G drives will be less than $200, one can put
> together 200G RAID systems for about $1000, a terabyte for about
> $5000. A database that would have needed an enterprise level system,
> just 7 years ago, can be run on a $500 desktop today.
If its too small for you, make a serial8 datatype (or something like
this), and use it for your tables. For me, I have tables which have very
few fields, and I don't want to waste 4 bytes/row (much less 8) for OID.
