Re: Deleting orphaned records to establish Ref Integrity

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

Browse pgsql-general by date

  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