On Wed, 3 Mar 2004, Chris Kratz wrote:
> Which certainly points to the triggers being the culprit. In reading the
> documentation, it seems like the "delete from only..." statement should
> ignore the constraint triggers. But it seems quite obvious from the
Delete from only merely means that children of the table being deleted
will not have their rows checked against any where conditions and removed
for that reason. It does not affect constraint triggers at all.
Given I'm guessing it's going to be running about 7000 * 67 queries to
check the validity of the delete for 7000 rows each having 67 foreign
keys, I'm not sure there's much to do other than hack around the issue
right now.
If you're a superuser, you could temporarily hack reltriggers on the
table's pg_class row to 0, run the delete and then set it back to the
correct number. I'm guessing from your message that there's never any
chance of a concurrent transaction putting in a matching row in a way that
something is marked as deletable when it isn't?
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
