Thread: Re: AW: Re: OID wraparound: summary and proposal

Re: AW: Re: OID wraparound: summary and proposal

From
mlw
Date:
I think you are focusing too much on "ROWID" and not enough on OID. The issue
at hand is OID. It is a PostgreSQL cluster wide limitation. As data storage
decreases in price, the likelihood of people running into this limitation
increases. I have run into OID problems in my curent project. Geez, 40G 7200
RPM drives are $120, amazing.

Tom has proposed being able to remove the OID from tables, to preserve this
resource. I originally thought this was a good idea, but there are tools and
utilities others may want to use in the future that require OIDs, thus they
would have to be re-written or abandoned altogether.

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.


Zeugswetter Andreas SB SD wrote:
> 
> > Some other databases have the notion of a ROWID which uniquely
> identifies a row
> > within a table. OID can be used for that, but it means if you use it,
> you must
> > limit the size of your whole database system.
> 
> Imho that is getting it all wrong. OID is *not* a suitable substitute
> for other
> db's ROWID.
> 
> If you take a few extra precautions then you can use XTID in PostgreSQL
> instead of other's ROWID.
> 
> We often hear, that it is safer to use ROWID in Oracle and Informix than
> in
> PostgreSQL. It is only true that the risc of getting at the wrong record
> is
> lower. Are you going to take chances when manipulating rows ? NO !
> Thus any sensible program working on ROWID's will have builtin
> precautions,
> like locking the table, or using additional where quals.
> 
> I am still of the opinion, that we should invent an alias ROWID at the
> SQL level
> for the current XTID. I do not think that it matters what datatype this
> ROWID is,
> an arbitrary string like xtid is sufficient, it does not need to be an
> integer.
> 
> Andreas

-- 
5-4-3-2-1 Thunderbirds are GO!
------------------------
http://www.mohawksoft.com


Re: AW: Re: OID wraparound: summary and proposal

From
Alex Pilosov
Date:
On Mon, 6 Aug 2001, mlw wrote:

> I think you are focusing too much on "ROWID" and not enough on OID. The issue
> at hand is OID. It is a PostgreSQL cluster wide limitation. As data storage
> decreases in price, the likelihood of people running into this limitation
> increases. I have run into OID problems in my curent project. Geez, 40G 7200
> RPM drives are $120, amazing.
Possibly you were using OIDs for what they weren't intended  ;)

> Tom has proposed being able to remove the OID from tables, to preserve
> this resource. I originally thought this was a good idea, but there
> are tools and utilities others may want to use in the future that
> require OIDs, thus they would have to be re-written or abandoned
> altogether.
What are these tools?

> 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.
I disagree. OID as it is now is a mandatory SERIAL that is added to every
table. Most tables don't need such a field, those which do, well, they can
keep it as it is now (global per-database), or, if you want per-table
sequence, just create a SERIAL field explicitly.