Re: [PATCHES] WIP: executor_hook for pg_stat_statements - Mailing list pgsql-hackers

From ITAGAKI Takahiro
Subject Re: [PATCHES] WIP: executor_hook for pg_stat_statements
Date
Msg-id 20080716104154.7860.52131E4D@oss.ntt.co.jp
Whole thread Raw
In response to Re: [PATCHES] WIP: executor_hook for pg_stat_statements  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCHES] WIP: executor_hook for pg_stat_statements  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> >> That raises the question of whether we should have ExecutorStart() and
> >> ExecutorEnd() hooks as well, to round things off.
> > Yeah, and also ExecutorRewind() hook.
>
> I'm happy to put in hooks that there's a demonstrated need for,

Hmm, ok. I just want to hook ExecutorRun, so I'll just propose to
add ExecutorRun_hook now.

The attached patch is the proposal. It adds two global symbols:
  * ExecutorRun_hook - replacing behavior of ExecutorRun()
  * standard_ExecutorRun() - default behavior of ExecutorRun()

And also modifies one funtion:
  * ExecuteQuery() - It passes prepared query's text to portal so that
        the prepared query's text is available at the executor level.
        This change is almost free because it copys only string pointer,
        not the string buffer.


The attached archive pg_stat_statements.tar.gz is a demonstration of
ExecutorRun_hook. It collect per-statement statistics of number of planned
and executed, plan cost, execution time, and buffer gets/reads/writes.
I'll happy if the addin will be accepted as contrib module, but if it is
not suitable, I'm willing to move it to pgFoundry.

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


Attachment

pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: [PATCHES] WITH RECURSIVE updated to CVS TIP
Next
From: Tom Lane
Date:
Subject: Re: PATCH: CITEXT 2.0 v3