Greetings,
* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> On 2018-Nov-28, Tom Lane wrote:
> > Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > > On 2018-Nov-28, Tom Lane wrote:
> > >> This would also entail rather significant overhead to find out schema
> > >> names and interpolate them into the text.
> >
> > > True. I was thinking that the qualified-names version of the query
> > > would be obtained via ruleutils or some similar mechanism to deparse
> > > from the parsed query tree (not from the original query text), where
> > > only pg_catalog is considered visible. This would be enabled using a
> > > GUC that defaults to off.
> >
> > Color me skeptical --- ruleutils has never especially been designed
> > to be fast, and I can't see that the overhead of this is going to be
> > acceptable to anybody who needs pg_stat_statements in production.
> > (Some admittedly rough experiments suggest that we might be
> > talking about an order-of-magnitude slowdown for simple queries.)
>
> Good point.
>
> Maybe we can save the OID array of schemas that are in search_path when
> the query is first entered into the statement pool, and produce the
> query_qn column only at the time the entry is interpreted (that is, when
> pg_stat_statements is query). ... oh, but that requires saving the plan
> tree too, which doesn't sound very convenient.
>
> Maybe just storing the search_path schemas (as Tomas already suggested)
> is sufficient for Sergei's use case? Do away with query_qn as such, and
> just have the user interpret the names according to the stored
> search_path.
Seems like what you'd really want is to store all the environment, not
just the search_path (consider the $user case...). Maybe saving just
the OIDs of the search_path and then using them later would also work
but it seems like we're just building up to tracking everything and
doing it piecemeal with an extra column added in this release, another
in the next release, etc..
Thanks!
Stephen