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?

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)---------------------------

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)---------------------------

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: