Re: Buffer usage in EXPLAIN and pg_stat_statements (review) - Mailing list pgsql-hackers

From Itagaki Takahiro
Subject Re: Buffer usage in EXPLAIN and pg_stat_statements (review)
Date
Msg-id 20091014171946.B1F3.52131E4D@oss.ntt.co.jp
Whole thread Raw
In response to Re: Buffer usage in EXPLAIN and pg_stat_statements (review)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Buffer usage in EXPLAIN and pg_stat_statements (review)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> 2. I do not understand the stuff with propagating counts into the top
> instrumentation node.  That seems like it's going to double-count those
> counts.  In any case it is 100% inconsistent to propagate only buffer
> counts that way and not any other resource usage.  I think you should
> drop the TopInstrument variable and the logic that propagates counts up.

It is required by contrib/pg_stat_statements. EXPLAIN wants per-node
accumulation, but pg_stat_statements wants the total number.

Is it enough to add a PG_TRY block to standard_ExecutorRun() to
cleanup TopInstrument on error? I'm working on your other comments,
but I cannot remove TopInstrument for pg_state_statements.

I considerd other approaches, but all of them require node-dependent
routines; for example, adding a function to walk through a plan tree
and accumulate instrumentations in it at pg_stat_statements. But it is
hard to be maintained on executor nodes changes. Are there any better idea?

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center




pgsql-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: Client application name
Next
From: Heikki Linnakangas
Date:
Subject: Hot standby, xlog_xact_assignment and unreported subxids.