Re: [PATCHES] WIP: executor_hook for pg_stat_statements

ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes:
> The attached patch is the proposal. It adds two global symbols:
>   * ExecutorRun_hook - replacing behavior of ExecutorRun()
>   * standard_ExecutorRun() - default behavior of ExecutorRun()

Applied.

> And also modifies one funtion:
>   * ExecuteQuery() - It passes prepared query's text to portal so that
>         the prepared query's text is available at the executor level.
>         This change is almost free because it copys only string pointer,
>         not the string buffer.

This patch is unsafe because the portal could outlive the cached plan
source (consider the case that a called function does a DEALLOCATE).
However, I don't see any compelling argument against doing a pstrdup
here.  I did that and also went around and made assumptions uniform
about always having a source string for a cached plan or Portal.
So ActivePortal->sourceText should be a safe thing to consult to
see the source text of the most closely nested query being executed.
(Inside a plpgsql function, for instance, this would be the current
SQL statement of the function.)

> The attached archive pg_stat_statements.tar.gz is a demonstration of
> ExecutorRun_hook. It collect per-statement statistics of number of planned
> and executed, plan cost, execution time, and buffer gets/reads/writes.

I don't think this works yet --- you are still using debug_query_string,
and you're assuming it will be consistent with ActivePortal->sourceText,
which it won't be in function calls and other situations.
        regards, tom lane