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

From Amit Kapila
Subject Re: Early Setup of instrumentation information in pg_stat_statements
Date
Msg-id CAA4eK1+R60fF8_kVhz3uOWkCDuj5V5zy=3T_kViH848m+DC+cw@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 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
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?


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: pg_basebackup may fail to send feedbacks.
Next
From: Michael Paquier
Date:
Subject: Re: Table-level log_autovacuum_min_duration