On 11/29/2018 12:46 PM, Tom Lane wrote:
> Alvaro Herrera <alvherre@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