Re: [PATCHES] WIP: executor_hook for pg_stat_statements

ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)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