From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
---|---|
To: | Adrian Klaver <aklaver(at)comcast(dot)net> |
Cc: | pgsql-general(at)postgresql(dot)org, Steve Crawford <scrawford(at)pinpointresearch(dot)com> |
Subject: | Re: Killing OIDs |
Date: | 2009-02-11 18:03:35 |
Message-ID: | 1234375415.31826.108.camel@jd-laptop.pragmaticzealot.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, 2009-02-11 at 18:01 +0000, Adrian Klaver wrote:
> ----- "Joshua D. Drake" <jd(at)commandprompt(dot)com> wrote:
> Now I am confused. From the docs I get:
>
My bad. The docs are obviously correct. I think I was thinking about the
postgresql.conf option.
Joshua D. Drae
> SET WITHOUT OIDS
>
> This form removes the oid column from the table. Removing OIDs from a table does not occur immediately. The space that the OID uses will be reclaimed when the row is updated. Without updating the row, both the space and the value of the OID are kept indefinitely. This is semantically similar to the DROP COLUMN process.
>
>
> I remember from past posts, that to get rid of the OIDS you can do a 'fake' update on the whole table to reclaim the space. The case the OP is dealing with he does not want the OID setting to propagate via the dump/restore cycle. The above statement would do that or am I mistaken?
>
>
> Thanks,
> Adrian Klaver
> aklaver(at)comcast(dot)net
>
--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Crawford | 2009-02-11 18:10:39 | Re: Killing OIDs |
Previous Message | Tom Lane | 2009-02-11 18:01:32 | Re: Killing OIDs |