Skip site navigation (1) Skip section navigation (2)

From: daniel alvarez <d-alvarez(at)gmx(dot)de>
To: pgsql-performance(at)postgresql(dot)org
Subject:
Date: 2003-02-26 13:04:39
Message-ID: 1859.1046264679@www36.gmx.net (view raw or flat)
Thread:
Lists: pgsql-performance
In some older mails in the archive I found rumors about difficulcies that
might
occur when OIDs are used as an integral part of a data model.

I am considering the option of placing an index on the already existing oid
and using
it as the primary key for all tables (saves some space and a sequence
lookup). This
includes saving the oid in foreign keys (virtual ones, not actually declared
references).
I read that using OID in keys is generally a bad idea. Is it really? Why
exactly?

Are there any disadvantages as to reliability or performance apart from
accidentally
forgetting to use the -o option with pg_dump? If so, please give details.

I felt especially worried by a postgres developer's statement in another
archived mail:
"As far as I know, there is no reason oid's have to be unique, especially if
they are in different tables."
(http://archives.postgresql.org/pgsql-hackers/1998-12/msg00570.php)

How unique are oids as of version 7.3 of postgres ?

Is it planned to keep oids semantically the same in future releases of
postgres?
Will the oid type be extended so that oids can be larger than 4 bytes (if
this is still
correct for 7.3) and do not rotate in large systems?


Thanks for your time and advice.

Daniel Alvarez <d-alvarez(at)gmx(dot)de>
 
 

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte l├Ącheln! Fotogalerie online mit GMX ohne eigene Homepage!


Responses

pgsql-performance by date

Next:From: Richard HuxtonDate: 2003-02-26 13:58:53
Subject: Re: OIDs as keys
Previous:From: Andrew SullivanDate: 2003-02-26 12:00:40
Subject: Re: Index File growing big.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group