From: | "Roman F" <romanf(at)fusemail(dot)com> |
---|---|
To: | "Greg Stark" <gsstark(at)mit(dot)edu>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Deleting orphaned records to establish Ref Integrity |
Date: | 2005-06-09 01:53:34 |
Message-ID: | 12423.65.74.139.37.1118282014.fusewebmail-71148@webmail.fusemail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>> Another idea is to try an outer join:
>> SELECT child_table.parentid INTO tmp_table
>> FROM child_table LEFT JOIN parent_table
>> ON (child_table.parentid = parent_table.parentid)
>> WHERE parent_table.parentid IS NULL;
>
>There's also
>DELETE
>FROM child_table
>WHERE NOT EXISTS (select 1
>from parent_table
>where parent_id = child_table.parent_id
>)
>
> Which won't use anything as efficient as a hash join or merge join but
will beat
> least capable of using index lookups for something basically equivalent toa
> nested loop.
Sorry for the delay, I only get to work on this system every now and then.
I tried Greg's suggestion and it worked out great. The estimates from
EXPLAIN were much larger than the actuals (e.g. 41 hours vs. 2 hours), so
I probably have some tuning to do with this dataset. I decided not to try
Tom's temp table method because I was afraid the generated table would be
very large, so the subsequent DELETE .. WHERE NOT IN (...) would cause
swapping again.
Thanks all for your help, your insights saved me a lot of headache.
Roman
_____________________________________
Consolidate your email!
http://www.fusemail.com
_____________________________________
Check All Email Accounts Anywhere!
Check your POP3 and webmail account
from any PC. With no ads
http://www.fusemail.com
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2005-06-09 02:25:19 | Re: So maybe SQLERRM? Sb knows how to check it? |
Previous Message | Geoffrey | 2005-06-09 01:29:15 | Re: IMPORTANT NOTIFICATION |