Re: Huge tables, trying to delete OID's taking 6+hours per table - Mailing list pgsql-general

From Ron
Subject Re: Huge tables, trying to delete OID's taking 6+hours per table
Date
Msg-id 0c0d572a-95ad-42ec-6977-8cd744ad0065@gmail.com
Whole thread Raw
In response to Re: Huge tables, trying to delete OID's taking 6+hours per table  (Tory M Blue <tmblue@gmail.com>)
Responses Re: Huge tables, trying to delete OID's taking 6+hours per table
List pgsql-general
On 5/19/20 11:51 AM, Tory M Blue wrote:


On Tue, May 19, 2020 at 6:40 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Tory M Blue <tmblue@gmail.com> writes:
> The command i'm using is
> ALTER TABLE tablename SET WITHOUT OIDS;
> Would a drop column oid be better?

Unfortunately, you're kind of stuck.  OIDs are not like regular columns
(at least before v12) --- they are integrated into the tuple header in
a hackish way, and so there's no way to get rid of them without a table
rewrite.

                        regards, tom lane

Poop :) kind of figured that, so it's just painful.

But  I guess if it's doing a table rewrite, is there any configuration params I could boost to help it? Shared_buffers, give it more, work mem, maintenance mem, temp buffers anything you can think of?

There's an alternative if this is a "transaction table" (named, in this example, FOO) which never gets updated (only inserted into and selected from).

Create a new, partitioned, oid-free copy of the table (named NEW_FOO) that's populated with most of the records (all except the most recent).  When ready to cut over, you'd stop the applications, copy over the most current records from FOO to NEW_FOO and then rename FOO to OLD_FOO and FOO to OLD_FOO.

Then you can drop OLD_FOO.

--
Angular momentum makes the world go 'round.

pgsql-general by date:

Previous
From: Tory M Blue
Date:
Subject: Re: Huge tables, trying to delete OID's taking 6+hours per table
Next
From: Santhosh Kumar
Date:
Subject: Configuring more than one hot standby server