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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PROPOSAL] extend the object names to the qualified names in pg_stat_statements
Дата
Msg-id 30119.1543520814@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PROPOSAL] extend the object names to the qualified names inpg_stat_statements  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: [PROPOSAL] extend the object names to the qualified names inpg_stat_statements  (Sergei Agalakov <sergei.agalakov@gmail.com>)
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Sergei Agalakov
Дата:
Сообщение: Re: [PROPOSAL] extend the object names to the qualified names inpg_stat_statements
Следующее
От: Dmitry Dolgov
Дата:
Сообщение: Re: Proposal for Signal Detection Refactoring