Here is an update version of contrib/auto_explain patch.
Now it uses new ExecutorStart_hook and ExecutorEnd_hook.
When we execute queries using cursor, FETCHes are accumulated
and reported only once on CLOSE.
A new argument 'flags' is added in DefineCustomXXXVariable()
and custom GUC variables are defined with it. Some GUC_* constants
are moved to guc.h from guc_tables.h.
A variable "Instrumentation *totaltime" is added in QueryDesc.
It is not used by the core in default (always NULL), but initialized
by contrib modules. However, the core update the counter if it is
not NULL because multiple contrib modules might use it.
If the core don't update the counter, only one of the modules
should update it, but it's hard to determine which one should do.
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> This would likely require adding a struct Instrumentation * field to
> Well, it's more general. You could think of ExecutorRun as being like a
> plan node, in which case all the fields of struct Instrumentation are
> potentially useful. If a contrib module doesn't want to use them,
> of course it doesn't have to.
Instrumentation is enough for auto_explain, so I used it for now.
However, pg_stat_statements also use the field and requires other
counters (buffer usages and rusage). It might replace the field
with another struct. Then we might need to reconsider how to deal
with session statistics, suggested by Vladimir.
"Vladimir Sitnikov" <sitnikov.vladimir@gmail.com> wrote:
> I wish PostgreSQL had some kind of pg_session_statistics view that reports
> resource usage statistics for each session.
> For instance, it could expose "buffer usage" to the client, so it could get
> more details on resource usage. For instance, I would like to see a new tab
> in pgAdmin that shows "total number of buffer gets", "number of WAL records
> created", "number of rows sorted" and similar information after query
> finishes (even in plain "execute" mode).
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center