Andrew Lazarus <andrew(at)pillette(dot)com> writes:
> I have a cascading delete trigger that is obviously using a seqscan.
> (Explain analyze shows that trigger as taking over 1000s while all
> other triggers are <1s. The value in test delete didn't even appear in
> this child table, so an index scan would have been almost instant.)
> If I do
> DELETE FROM child_table WHERE fkey = value;
> I get an index scan. Why doesn't the trigger do that, and how can I
> force it to re-plan?
That would depend on what PG version you're using.
However, starting a fresh connection should get you a new trigger
function plan in any case.
regards, tom lane
In response to
pgsql-performance by date
|Next:||From: Dimitri Fontaine||Date: 2008-02-26 12:08:53|
|Subject: multi-threaded pgloader needs your tests|
|Previous:||From: Sean Leach||Date: 2008-02-25 23:32:10|
|Subject: Re: Weird issue with planner choosing seq scan|