On 26 February 2011 05:55, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Further experimentation has reminded me of why I didn't want to put such
> processing in ExecutorEnd :-(. There are some nasty interactions with
> EXPLAIN:
>
> 1. EXPLAIN ANALYZE fails to include the execution cycles associated with
> running the ModifyTable nodes to completion. In the worst case, such as
> "WITH t AS (INSERT ...) SELECT 1", it will claim the INSERT subplan is
> never executed, even though rows certainly got inserted. This is
> because EXPLAIN extracts all the counts from the execution state tree
> before shutting it down with ExecutorEnd.
>
> 2. But it gets worse. Try the same query *without* ANALYZE. You'll
> find the INSERT executes anyway! That's because EXPLAIN still calls
> ExecutorEnd to clean up the execution state tree, and ExecutorEnd
> doesn't realize it's not supposed to run any of the plan.
>
There's a third problem: AfterTriggerEndQuery() is called before
ExecutorEnd(), and so if the post-processing is done in ExecutorEnd()
and it attempts to queue up any AFTER triggers, it fails (ERROR:
AfterTriggerSaveEvent() called outside of query).
> So we really need some refactoring here. I dislike adding another
> fundamental step to the ExecutorStart/ExecutorRun/ExecutorEnd sequence,
> but there may not be a better way. The only way I see to fix this
> without changing that API is to have ExecutorRun do the cleanup
> processing just after the top plan node returns a null tuple, and that
> seems a bit ugly as well.
>
> Thoughts?
>
Could the post-processing not be done at the end of ExecutePlan()?
Regards,
Dean
