Re: wCTE: why not finish sub-updates at the end, not the beginning?

On 26 February 2011 05:55, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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