From: | Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Euler Taveira de Oliveira <euler(at)timbira(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Buffer usage in EXPLAIN and pg_stat_statements (review) |
Date: | 2009-10-14 08:44:22 |
Message-ID: | 20091014171946.B1F3.52131E4D@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2009-10-14 11:43:46 | Hot standby, xlog_xact_assignment and unreported subxids. |
Previous Message | Dave Page | 2009-10-14 07:27:43 | Re: Client application name |