Обсуждение: Unbearably slow cascading deletes

I have (among other things) a parent table with 200 records and a child table with 20MM or more. I set up referential
integrityon the FK with ON DELETE CASCADE. 

It appears that when a DELETE is done on the parent table, the child table deletion is done with a sequential scan. I
saythis because it took over four minutes to delete a parent record THAT HAD NO CHILDREN. The DB is recently analyzed
andSELECTs in the child table are done by the appropriate index on the FK. 

Let me guess, the cascade trigger's query plan is decided at schema load time, when the optimizer has no clue. Is there
away to fix this without writing my own triggers, using PL/PGSQL EXECUTE to delay the planner? 

And by the way, if FK conditions like IN (1,3,4) could be handled in a single invocation of the trigger, so much the
better.

On Tue, 20 Jul 2004 andrew@pillette.com wrote:

> I have (among other things) a parent table with 200 records and a child
> table with 20MM or more. I set up referential integrity on the FK with
> ON DELETE CASCADE.
>
> It appears that when a DELETE is done on the parent table, the child
> table deletion is done with a sequential scan. I say this because it
> took over four minutes to delete a parent record THAT HAD NO CHILDREN.
> The DB is recently analyzed and SELECTs in the child table are done by
> the appropriate index on the FK.
>
> Let me guess, the cascade trigger's query plan is decided at schema load
> time, when the optimizer has no clue. Is there a way to fix this without
> writing my own triggers, using PL/PGSQL EXECUTE to delay the planner?

The query plan should be decided at the first cascaded delete for the key
in the session. However, IIRC, it's using $arguments for the key values,
so it's possible that that is giving it a different plan than it would get
if the value were known.  What do you get if you prepare the query with an
argument for the key and use explain execute?

On Tue, 20 Jul 2004, Stephan Szabo wrote:

>
> On Tue, 20 Jul 2004 andrew@pillette.com wrote:
>
> > I have (among other things) a parent table with 200 records and a child
> > table with 20MM or more. I set up referential integrity on the FK with
> > ON DELETE CASCADE.
> >
> > It appears that when a DELETE is done on the parent table, the child
> > table deletion is done with a sequential scan. I say this because it
> > took over four minutes to delete a parent record THAT HAD NO CHILDREN.
> > The DB is recently analyzed and SELECTs in the child table are done by
> > the appropriate index on the FK.
> >
> > Let me guess, the cascade trigger's query plan is decided at schema load
> > time, when the optimizer has no clue. Is there a way to fix this without
> > writing my own triggers, using PL/PGSQL EXECUTE to delay the planner?
>
> The query plan should be decided at the first cascaded delete for the key
> in the session. However, IIRC, it's using $arguments for the key values,
> so it's possible that that is giving it a different plan than it would get
> if the value were known.  What do you get if you prepare the query with an
> argument for the key and use explain execute?

To be clear, I mean prepare/explain execute an example select/delete from
the fk.

PREPARE c(int4) AS DELETE FROM childtable WHERE fk=$1;
EXPLAIN EXECUTE c(-1);

gives an index scan.

PREPARE c2(int4) AS DELETE FROM parenttable WHERE key=$1;
EXPLAIN EXECUTE c2(1);

gives a seq scan on the parent table (itself a little curious) and no explanation of what the triggers are doing.

I FOUND IT!

A second trigger that doesn't belong......

OK, we're set now, and thanks for showing me some ways to check what the planner is up to. Is there a way of seeing
whatthe triggers will do? 

> I have (among other things) a parent table with 200 records and a child table with 20MM or more. I set up referential
integrityon the FK with ON DELETE CASCADE. 
>
> It appears that when a DELETE is done on the parent table, the child table deletion is done with a sequential scan. I
saythis because it took over four minutes to delete a parent record THAT HAD NO CHILDREN. The DB is recently analyzed
andSELECTs in the child table are done by the appropriate index on the FK. 

Do you have an index on the foreign key field?

Chris