Thread: Thought on OIDs
Hi! A thought just hit me and I got a bit worried... If OIDs are "globaly" unique and I have a very high data-throughput on my database, i.e. I do a lot of inserts and deletes, is it then possible to "run out" of OIDs? If this can occur, will it cause any problems? Need I worry? =) Regards, Patrik Kudo
> Hi! > > A thought just hit me and I got a bit worried... If OIDs are "globaly" > unique and I have a very high data-throughput on my database, i.e. I do a > lot of inserts and deletes, is it then possible to "run out" of OIDs? If > this can occur, will it cause any problems? Yes it can happen, yes it will cause problems.. > Need I worry? =) It depends on how busy "busy" is to you :-) There was a rather long thread about this a few weeks ago, I believe there was discussion of wrapping OIDs but I'm not sure how the conversation turned out -- one of the core developers will have to comment.. -Mitch
Quoting Patrik Kudo <kudo@partitur.se>: > Hi! > > A thought just hit me and I got a bit worried... If OIDs are "globaly" > unique and I have a very high data-throughput on my database, i.e. I do > a > lot of inserts and deletes, is it then possible to "run out" of OIDs? > If > this can occur, will it cause any problems? > > Need I worry? =) Have you thought about how many inerts, time, etc you would need to fill all the oids? System Administration: It's a dirty job, but someone told I had to do it. ----------------------------------------------------------------- Martín Marqués email: martin@math.unl.edu.ar Santa Fe - Argentina http://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -----------------------------------------------------------------
Someones bound to hit it in a year or 2 as Postgres is getting pretty good for large projects as well as the small, especially with 7.1's speed enhancements. Hopefully 7.2 will create cycling OIDs and XIDs. Then less problems in 'unlimited' extendability. -- Rod Taylor There are always four sides to every story: your side, their side, the truth, and what really happened. ----- Original Message ----- From: "Martin A. Marques" <martin@math.unl.edu.ar> To: "Patrik Kudo" <kudo@partitur.se> Cc: <pgsql-general@postgresql.org> Sent: Friday, March 02, 2001 9:52 AM Subject: [GENERAL] Re: Thought on OIDs > Quoting Patrik Kudo <kudo@partitur.se>: > > > Hi! > > > > A thought just hit me and I got a bit worried... If OIDs are "globaly" > > unique and I have a very high data-throughput on my database, i.e. I do > > a > > lot of inserts and deletes, is it then possible to "run out" of OIDs? > > If > > this can occur, will it cause any problems? > > > > Need I worry? =) > > Have you thought about how many inerts, time, etc you would need to fill all the > oids? > > > System Administration: It's a dirty job, > but someone told I had to do it. > ----------------------------------------------------------------- > Martín Marqués email: martin@math.unl.edu.ar > Santa Fe - Argentina http://math.unl.edu.ar/~martin/ > Administrador de sistemas en math.unl.edu.ar > ----------------------------------------------------------------- > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
Rod Taylor writes: > Someones bound to hit it in a year or 2 as Postgres is getting pretty > good for large projects as well as the small, especially with 7.1's > speed enhancements. Hopefully 7.2 will create cycling OIDs and XIDs. > Then less problems in 'unlimited' extendability. The easiest approach for OIDs will probably be making them optional in the first place. For the vast majority of users, the OIDs are just wasting space. The cycling XID idea is based on the assertion that eventually all transactions will be closed, at which time a record is either known committed or known dead so that the XID can be recycled. For OIDs, this is not practical. And if you wanted OIDs that automatically fill in the holes, that's probably not realistic. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
I use XID's regularly now for historical purposes (delayed reversion of entire operations -- handled by an interface of course where appropriate) but OID's I could certainly live without. However, PHP currently returns the OID in from pg_getlastoid() which I use to select from the table the last PRIMARY KEY entry. Getting this key before sometimes isn't an option (triggers handle them sometimes). If I could have a pg_getlastprimarykey() function which returns a hash of name / value pairs of the new key without using the OID it would be ideal. -- Rod Taylor There are always four sides to every story: your side, their side, the truth, and what really happened. ----- Original Message ----- From: "Peter Eisentraut" <peter_e@gmx.net> To: "Rod Taylor" <rod.taylor@inquent.com> Cc: <pgsql-general@postgresql.org> Sent: Friday, March 02, 2001 11:31 AM Subject: Re: [GENERAL] Re: Thought on OIDs > Rod Taylor writes: > > > Someones bound to hit it in a year or 2 as Postgres is getting pretty > > good for large projects as well as the small, especially with 7.1's > > speed enhancements. Hopefully 7.2 will create cycling OIDs and XIDs. > > Then less problems in 'unlimited' extendability. > > The easiest approach for OIDs will probably be making them optional in the > first place. For the vast majority of users, the OIDs are just wasting > space. > > The cycling XID idea is based on the assertion that eventually all > transactions will be closed, at which time a record is either known > committed or known dead so that the XID can be recycled. For OIDs, this > is not practical. And if you wanted OIDs that automatically fill in the > holes, that's probably not realistic. > > -- > Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
I personally would like to see 8byte OIDs or at least int8 sequences, I'm a little worried about the pain of managing a potential rollover when I'm using sequences as a replication key between servers. Alex. On Fri, 2 Mar 2001, Peter Eisentraut wrote: > Rod Taylor writes: > > > Someones bound to hit it in a year or 2 as Postgres is getting pretty > > good for large projects as well as the small, especially with 7.1's > > speed enhancements. Hopefully 7.2 will create cycling OIDs and XIDs. > > Then less problems in 'unlimited' extendability. > > The easiest approach for OIDs will probably be making them optional in the > first place. For the vast majority of users, the OIDs are just wasting > space. > > The cycling XID idea is based on the assertion that eventually all > transactions will be closed, at which time a record is either known > committed or known dead so that the XID can be recycled. For OIDs, this > is not practical. And if you wanted OIDs that automatically fill in the > holes, that's probably not realistic. > > -- > Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >