On Wednesday 26 Feb 2003 1:04 pm, daniel alvarez wrote:
> In some older mails in the archive I found rumors about difficulcies that
> 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
OIDs are not even guaranteed to be there any more - you can create a table
WITHOUT OIDs if you want to save some space. If you want a numeric primary
key, I'd recommend int4/int8 attached to a sequence - it's much clearer
what's going on then.
> Are there any disadvantages as to reliability or performance apart from
> 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."
> How unique are oids as of version 7.3 of postgres ?
OIDs are unique per object (table) I believe, no more so. See chapter 5.10 of
the user guide for details. They are used to identify system objects and so
the fact that a function and a table could both have the same OID should
cause no problems.
> Is it planned to keep oids semantically the same in future releases of
Couldn't say - don't see why not.
> 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?
Strikes me as unlikely, though I'm not a developer. Look into 8-byte
In response to
- at 2003-02-26 13:04:39 from daniel alvarez
pgsql-performance by date
|Next:||From: daniel alvarez||Date: 2003-02-26 14:59:35|
|Subject: Re: OIDs as keys|
|Previous:||From: daniel alvarez||Date: 2003-02-26 13:04:39|