From: | Sergei Agalakov <sergei(dot)agalakov(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
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 19:16:09 |
Message-ID: | cbcdb4d5-7a74-5ff7-9acb-314023132284@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/29/2018 10:47 AM, Alvaro Herrera wrote:
> On 2018-Nov-28, Tom Lane wrote:
>
>> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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.
>
I thought about just saving the search_path. It has all the necessary
information for a DBA or a developer, but creates problems for reporting
tools.
If we have the new query_qn column then we can group statistics by
query_qn and display it on the charts and graphs.
If instead we use a combination of query and search_path then a
reporting tools has to figure out the way to show both values to
distinguish between
different versions of query.
If it is easier/faster to add search_path then let's add search_path
instead of query_qn. It is already documented that query text isn't
unique by itself,
and reporting tools have to use query+queryid for uniqueness, and
search_path will provide the currently unavailable information to the
DBAs/developers.
Good.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-11-29 19:46:54 | Re: [PROPOSAL] extend the object names to the qualified names in pg_stat_statements |
Previous Message | Dmitry Dolgov | 2018-11-29 19:13:25 | Re: libpq compression |