From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in> |
Cc: | PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: 7.3.1 takes long time to vacuum table? |
Date: | 2003-02-20 16:05:46 |
Message-ID: | 20030220080314.L46188-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, 20 Feb 2003, Shridhar Daithankar wrote:
> On 20 Feb 2003 at 13:03, Mark Cave-Ayland wrote:
> > And the result? It has taken a total of 1h 45m to generate a copy! Given
> > that we are rebuilding the table *WITHOUT* the large gist indexes on our
> > dev version, I guess that it would only be a matter of several hours
> > before we can rebuild the indexes back up on the table and be using it
> > again.
>
> OK. From last thread, there was one more bell of caution. Having foreign key
> constraints.
>
> What I would suggest you to do is as follows.
>
> beign
>
> create new table as select into..
> create any necessary indexes on new table.
> rename old table as something else.
> rename new table as original table
>
> commit
>
> drop old table.
>
> It should take care of mos practical problems that I can think of, right now.
That won't copy foreign key constraints, unfortuntately. Foreign keys
aren't to a name, they're to an object, so a constraint to the old table
is still to the old table no matter what you rename it to and if something
else is renamed to the the old table's old table.
From | Date | Subject | |
---|---|---|---|
Next Message | greg | 2003-02-20 16:23:10 | Re: Four questions |
Previous Message | greg | 2003-02-20 16:03:19 | Re: Removing spaces |