| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Sergei Agalakov <sergei(dot)agalakov(at)gmail(dot)com>, 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:46:54 |
| Message-ID: | 30119.1543520814@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dmitry Dolgov | 2018-11-29 19:47:42 | Re: Proposal for Signal Detection Refactoring |
| Previous Message | Sergei Agalakov | 2018-11-29 19:16:09 | Re: [PROPOSAL] extend the object names to the qualified names in pg_stat_statements |