Re: pg_stat_statements produces multiple entries for a single query with track = 'top' - Mailing list pgsql-bugs

From Peter Geoghegan
Subject Re: pg_stat_statements produces multiple entries for a single query with track = 'top'
Date
Msg-id CAM3SWZTftnL5C2THwr49WkX6U60Fe86ujuup544YQ33jZterdw@mail.gmail.com
Whole thread Raw
In response to Re: pg_stat_statements produces multiple entries for a single query with track = 'top'  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Sat, Aug 10, 2013 at 5:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Isn't this just the behavior we decided we wanted for SQL-language
> functions?  At least, if we change pg_stat_statements so it doesn't
> break out SQL-language functions, I'm sure somebody's gonna complain.

Perhaps there was some discussion of this with Takahiro Itagaki, but I
have no recollection of having been involved in or having followed a
discussion about pg_stat_statements behavior with regards to
SQL-language functions in particular. Actually, if Itagaki-san had
discussed this, there is a reasonably good chance that I'd have read
it before now.

I can tell you that at the very least, this behavior does not seem
consistent with the documentation:

"pg_stat_statements.track controls which statements are counted by the
module. Specify top to track top-level statements (those issued
directly by clients), all to also track nested statements (such as
statements invoked within functions), or none to disable statement
statistics collection. The default value is top. Only superusers can
change this setting."

Clearly the statement "SELECT '6378168'::float8" was not directly
issued by the client here.

If this is the behavior we want for SQL functions, that is something
that ought to be highlighted as a special case.

--
Peter Geoghegan

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_stat_statements produces multiple entries for a single query with track = 'top'
Next
From: karsten.lenz@gmx.ch
Date:
Subject: BUG #8380: initdb ignore options