From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | pg noob <pgnube(at)gmail(dot)com> |
Cc: | pgsql-novice <pgsql-novice(at)postgresql(dot)org> |
Subject: | Re: best way to do bulk delete? |
Date: | 2011-10-28 17:01:30 |
Message-ID: | CAHyXU0xMOE39WYHO5eGyk4uoE_HDVXH1rsssvJP-+DsAHFAXRQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
On Fri, Oct 28, 2011 at 11:47 AM, pg noob <pgnube(at)gmail(dot)com> wrote:
>
> Thank you. That approach looks promising.
> When you say that it is not side effect free, are there any other side
> effects other than the composite types one you mentioned?
> I don't believe these tables contain any composite types so it shouldn't be
> an issue.
>
> I tested it and found that there is no ALTER TABLE <foo> RENAME to <bar>
> CASCADE.
whoops -- the CASCADE was supposed to be after the DROP TABLE.
> Where this approach seems to break down is when the table has a lot of
> dependent objects (dependent constraints, functions, views, triggers, etc.).
> I could use DROP CASCADE but then I would also need to save and recreate all
> those dependent objects as well.
>
> But for simple tables that don't have a lot of dependent objects your
> suggested approach seems like it can work well.
correct -- you have to rebuild all that stuff. if you structure your
code properly though, that should be pretty doable. again though -- a
partitioning strategy might be the best way to go long term though.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Arvind Sharma | 2011-10-28 17:02:34 | Re: PgAdmin III shows removed PostgreSQL |
Previous Message | pg noob | 2011-10-28 16:47:48 | Re: best way to do bulk delete? |