Re: OIDs (Or: another RTFM question?)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Adrian 'Dagurashibanipal' von Bidder" <avbidder(at)fortytwo(dot)ch>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: OIDs (Or: another RTFM question?)
Date: 2002-07-16 16:15:44
Message-ID: 13168.1026836144@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Adrian 'Dagurashibanipal' von Bidder" <avbidder(at)fortytwo(dot)ch> writes:
> But I'm missing discussion about significance of the oids - something
> along the lines of 'Creating tables WITHOUT OIDS does *not* safe any
> disk space, but does <give you what?> at the expense of <what? being not
> backward compatible, I guess>.'

Basically what WITHOUT OIDS does for you is to reduce consumption of
OIDs, thereby postponing wraparound of the 32-bit OID counter. While
the system itself isn't fazed by such a wraparound, user programs that
look at OIDs might be. Also, you might get some transient command
failures due to duplicated OIDs --- eg, a CREATE TABLE might fail if the
generated OID for the table matches one already in pg_class. (If so,
you can just keep trying till you get a non-duplicate OID, but the
annoyance factor could be considerable ... especially if the CREATE is
issued by an application that's not prepared for it to fail.)

In the long run there is talk of assigning OIDs per-table instead of
globally, so that consumption of OIDs in user tables wouldn't cause
problems for any other table.

Also, there is work being done to make WITHOUT OIDS actually save space
in row headers; that may happen for 7.3.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Neil Conway 2002-07-16 16:18:22 Re: Inquiry From Form [pgsql]
Previous Message Doug McNaught 2002-07-16 16:13:14 Re: Question: merit / feasibility of compressing frontend