| From: | Andrew Lazarus <andrew(at)pillette(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: when is a DELETE FK trigger planned? |
| Date: | 2008-02-28 00:54:20 |
| Message-ID: | 1069587644.20080227165420@pillette.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
I figured out what appears to happen with cascading delete using a
seqscan. In this case, the foreign keys in the child table are not
equally distributed. A few parent values occur often. Most parent
values do not occur at all. So the planner, faced with an unknown
generic key, takes the safe route.
What I've done is remove the FK (maybe it would be better to leave it
albeit disabled for documentation) and written my own AFTER DELETE
trigger that uses EXECUTE to delay planning until the actual value is
known. This appears to work correctly.
--
Sincerely,
Andrew Lazarus mailto:andrew(at)pillette(dot)com
| Attachment | Content-Type | Size |
|---|---|---|
| vCard.VCF | text/x-vcard | 377 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joel Stevenson | 2008-02-28 02:19:12 | Re: LISTEN / NOTIFY performance in 8.3 |
| Previous Message | Tom Lane | 2008-02-27 23:37:44 | Re: disabling an index without deleting it? |