Re: [PROPOSAL] extend the object names to the qualified names in pg_stat_statements

From: Sergei Agalakov <sergei(dot)agalakov(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PROPOSAL] extend the object names to the qualified names in pg_stat_statements
Date: 2018-11-29 20:23:26
Message-ID: 596fade1-f230-581b-ac36-b0eae906cedd@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/29/2018 12:46 PM, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-11-29 20:44:09 Re: pg_config wrongly marked as not parallel safe?
Previous Message Sergei Agalakov 2018-11-29 20:12:24 Re: [PROPOSAL] extend the object names to the qualified names in pg_stat_statements