Re: pg_stat_statements and non default search_path

On 16 Oct. 2016 14:31, "Julien Rouhaud" <julien(dot)rouhaud(at)dalibo(dot)com> wrote:
>
> On 16/10/2016 02:38, Jim Nasby wrote:
> > On 10/10/16 12:58 AM, Julien Rouhaud wrote:
> >> Unless you mean deparsing the Query instead of using raw source text?
I
> >> think that would solve this issue (and also the other issue when
> >> multiple queries are submitted at once, you get the normalized version
> >> of all the queries multiple time), but AFAIK ruleutils.c doesn't expose
> >> enough to do it (like get_query_def()), and exposing it isn't an
option.
> >
> > Why couldn't we expose it?

I'm interested in that too, for the purpose of passing the correct
substring of a multi-statement to ProcessUtility_hook. Perhaps by using
parser position data to generate a start pointer and length within the
querystring already passed.

For the problem in this thread one could always implement plan-to-query
transforms (deparse). But you'd get back something pretty far from the
input query after function inlining, subquery flattering, condition
pushdown/pullup, join elimination, etc etc.

I think pg_stat_plans attempted a middle ground here, capturing explain
style plans rather than trying to report the SQL.

I do think there is utility to storing search_path and optionally
specialising stats according to it. The most obvious case is multi-tenant
and schema-sharded models where per-schema stats would be very handy. You'd
want to use the active search path though so you eliminate references to
nonexistent schemas. Otherwise $user would screw things up.