Unix Technical Forum

Re: [PATCHES] WIP: executor_hook for pg_stat_statements

This is a discussion on Re: [PATCHES] WIP: executor_hook for pg_stat_statements within the pgsql Hackers forums, part of the PostgreSQL category; --> ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes: > The attached patch is the proposal. It adds two global symbols: > * ExecutorRun_hook ...


Go Back   Unix Technical Forum > Database Server Software > PostgreSQL > pgsql Hackers

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #11 (permalink)  
Old 07-22-2008, 07:58 AM
Tom Lane
 
Posts: n/a
Default Re: [PATCHES] WIP: executor_hook for pg_stat_statements

ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes:
> The attached patch is the proposal. It adds two global symbols:
> * ExecutorRun_hook - replacing behavior of ExecutorRun()
> * standard_ExecutorRun() - default behavior of ExecutorRun()


Applied.

> 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.


This patch is unsafe because the portal could outlive the cached plan
source (consider the case that a called function does a DEALLOCATE).
However, I don't see any compelling argument against doing a pstrdup
here. I did that and also went around and made assumptions uniform
about always having a source string for a cached plan or Portal.
So ActivePortal->sourceText should be a safe thing to consult to
see the source text of the most closely nested query being executed.
(Inside a plpgsql function, for instance, this would be the current
SQL statement of the function.)

> 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 don't think this works yet --- you are still using debug_query_string,
and you're assuming it will be consistent with ActivePortal->sourceText,
which it won't be in function calls and other situations.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 08:43 PM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
SEO by vBSEO 3.2.0
www.UnixAdminTalk.com