Message-ID: <55BE3BCC.7000109@splivalo.hr>
Date: Sun, 02 Aug 2015 17:48:28 +0200
From: Mario Splivalo <mario@splivalo.hr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: pgsql-sql@postgresql.org
Subject: Re: Re: Getting the list of foreign keys (for deleting data
 from the database)
References: <55BE3180.5020600@splivalo.hr> <mplcf8$fgf$1@ger.gmane.org>
In-Reply-To: <mplcf8$fgf$1@ger.gmane.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-sql-owner@postgresql.org

On 08/02/2015 05:20 PM, Thomas Kellerer wrote:
> Mario Splivalo schrieb am 02.08.2015 um 17:04:
>> Suppose I have a table_detail that has column table_id which is FK
>> pointing to table(id), I would need to do  something like this:
>>
>> SELECT foo_drop_all_constraints();
>> SELECT * FROM table INTO table_copy WHERE date_created >= '2015-01-01';
>> SELECT table_detail.* INTO table_detail_copy FROM table_detail JOIN
>> table_copy ON table_detail.table_id = table_copy.id
>> DROP TABLE table;
>> DROP TABLE table_copy
>> ALTER TABLE table_copy RENAME TO table;
>> ALTER TABLE table_detail_copy TO table_detail;
>> SELECT foo_restore_all_constraints();
>>
>> Now, what am I asking is - is there a tool which would help me find all
>> the _detail tables? I know I could query pg_constraints and similar
>> views but before I go onto hacking into those I'm wondering if there is
>> something that could aid me in doing so.
> 
> The SQL tool I maintain (http:://www.sql-workbench.net) has such a feature.
> 
> It supports a (SQL Workbench specific) command that generates
> (recursively) the delete
> statements starting with the "root" table given a condition on the root
> table:
> 
>    http://www.sql-workbench.net/manual/wb-commands.html#command-gendelete

Oho! Thank you, I will check this out immediately!
> 
> The generated SQL script honors the FKs and thus there is no need to
> drop all constraints.

The main reason for dropping FKs is because of the speed. It is WAY
faster to copy non-deleting data to a new (temporary) table, then drop
originating table and then rename the temporary table.

> 
> In your case it would be something like:
> 
>    WbGenerateDelete -table=root_table -columnValue="date_created >=
> '2015-01-01'";
> 
> The output is a script with the DELETEs in the right order - or at least
> it _should_.
> 
> I have to admit that I had to deal with one or two really large schemas
> (> 700 tables) where the
> delete statements where not ordered properly, especially if there are
> multiple FKs to/from the
> same table.
> 
> Note that the generated statements are not pretty and far from being
> efficient.

We'll see. If I can adapt/change those so that they INSERT INTO instead
of DELETE, then I'm 'riding on horse' (I'm on donkey now).

>  
>> Of course, if this is not the best approach I'd appreciate different
>> views/opinions.
> 
> In my experience, setting all the FKs to "on delete cascade" and
> properly indexing the FK
> columns is very often faster than doing the deletes all "manually".

All the constraints are set to 'on delete cascade' - deleting data just
from the top-most tables currently takes over 3 days to complete.

> Another option (if you need to do that very often) is to partition the
> tables by e.g. year.
> Then getting rid of all the data for a year is as simple as dropping the
> partitions for that year.

Yup, this is a very good suggestion! But for now I first need to get rid
of 'unneeded' data from the database.

> However partitioning and foreign key constraints don't work together in
> Postgres, which is a real shame.

+1

	Mario

-- 
Mario Splivalo
mario@splivalo.hr

"I can do it quick, I can do it cheap, I can do it well. Pick any two."


-- 
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql