Re: [PROPOSAL] extend the object names to the qualified names inpg_stat_statements
От | Sergei Agalakov |
---|---|
Тема | Re: [PROPOSAL] extend the object names to the qualified names inpg_stat_statements |
Дата | |
Msg-id | 596fade1-f230-581b-ac36-b0eae906cedd@gmail.com обсуждение исходный текст |
Ответ на | Re: [PROPOSAL] extend the object names to the qualified names in pg_stat_statements (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: