Re: Early Setup of instrumentation information in pg_stat_statements

On Thu, Feb 5, 2015 at 10:28 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> Currently in pg_stat_statements, the setup to track
> instrumentation/totaltime information is done after
> ExecutorStart(). Can we do this before ExecutorStart()?
> In particular, I am referring to below code:
>
> static void
> pgss_ExecutorStart(QueryDesc *queryDesc, int eflags)
> {
> ..
> standard_ExecutorStart(queryDesc, eflags);
> ..
> if (pgss_enabled() && queryDesc->plannedstmt->queryId != 0)
> {
> ..
> if (queryDesc->totaltime == NULL)
> {
> ..
> queryDesc->totaltime = InstrAlloc(1, INSTRUMENT_ALL);
> ..
> }
> }
> }
>
> The reason why I am asking is that to track instrumentation
> information (like buffer usage parameters) in case of parallel
> sequence scan, we need to pass this information at start of
> backend workers which are started in ExecutorStart() phase
> and at that time, there is no information available which can
> guarantee (we have queryId stored in planned stmt, but I think
> that is not sufficient to decide) that such an information is
> needed by plugin. This works well for Explain statement as
> that has the information for instrumentation available before
> ExecutorStart() phase.
>
> Please suggest me if there is a better way to make this
> information available in ExecutorStart() phase?

This seems like a clue that maybe starting the workers during the
ExecutorStart() phase is a bad idea. It might be a bad idea for other
reasons, too: what happens if that node never gets executed? I think
the general pattern of executor nodes is that they're not supposed to
do any real work until somebody tries to pull a tuple from them.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company