Thread: Re: AW: Re: OID wraparound: summary and proposal
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
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.