Re: Early Setup of instrumentation information in pg_stat_statements - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Early Setup of instrumentation information in pg_stat_statements
Date
Msg-id CA+TgmobZs+ZOPpVywXFT__gtWi02No7mCwZE9CEcYPUysKNy6w@mail.gmail.com
Whole thread Raw
In response to Early Setup of instrumentation information in pg_stat_statements  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Thu, Feb 5, 2015 at 10:28 AM, Amit Kapila <amit.kapila16@gmail.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Parallel Seq Scan
Next
From: Robert Haas
Date:
Subject: Re: Parallel Seq Scan