On 11/29/2018 12:46 PM, Tom Lane wrote:
Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
On 2018-Nov-28, Tom Lane wrote:
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.
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.
Yeah, and any subsequent DDL on relevant tables would break it.
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.
This'd be OK by me, though I'm not sure that it represents a convenient
solution for the original problem.
regards, tom lane
It's less convenient, but it presents a solution. Either that or even
better a new session_info column that
may capture together with search_path also current_user, session_user
etc. that would allow to distinct
between the different versions of the query based on the real context of
execution.
Thank you,
Sergei
