On Sat, Aug 10, 2013 at 5:45 PM, Tom Lane 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
Peter Geoghegan writes:
> So with this single earthdistance query, there are multiple
> invocations of the executor, and thus multiple associated
> pg_stat_statements entries (one with 4 "calls").
Isn't this just the behavior we decided we wanted for SQL-language
functions? At least, if we chang
While at 2ndQuadrant, I was responsible for a project called
pg_stat_plans, which as some people subscribed to this mailing list
will be aware is essentially a tool for instrumenting Postgres query
execution costs at the plan granularity rather than at the query
granularity. It is derivative of pg_
