Обсуждение: Early Setup of instrumentation information in pg_stat_statements
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:
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?
On Thu, Feb 5, 2015 at 8:58 PM, 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()?
On further analyzing, I found that currently it is done after
>
> Currently in pg_stat_statements, the setup to track
> instrumentation/totaltime information is done after
> ExecutorStart(). Can we do this before ExecutorStart()?
On further analyzing, I found that currently it is done after
ExecutorStart() because we want to allocate Instrumentation info
in per-query context which is allocated in ExecutorStart(), but I wonder
why can't it be done inside ExecutorStart() after per-query context is
available. Currently backend (standard_ExecutorRun()) takes care
of updating the stats/instrumentation info for a plugin (pg_stat_statements)
and the same is initialized by plugin itself, won't it be better that
both the operations be done by backend as backend has more
knowledge when it is appropriate to initialize or update and plugin
needs to just indicate that it needs stats.
Does anyone sees problem with doing it in above way or can think of
a better way such that this information (that plugin needs stats) can be
made available in ExecutorStart phase?
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