Re: Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

Поиск
Список
Период
Сортировка
От Lukas Fittl
Тема Re: Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)
Дата
Msg-id CAP53PkxjvRhR7JrKaqM6YouqCMGR4s=VqSXC8xZtPmgJvAuj-A@mail.gmail.com
обсуждение исходный текст
Ответ на Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)  ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>)
Список pgsql-hackers
Дерево обсуждения
On Mon, Nov 23, 2015 at 11:53 PM, Peter Geoghegan <pg@heroku.com> wrote:
One specific justification he gave for not using pg_stat_statements was:

"Doesn’t merge bind vars in IN()" (See slide #11)

I wonder:

* How do other people feel about this? Personally, I've seen enough
problems of this kind in the field that "slippery slope" arguments
against this don't seem very compelling.

As someone who runs a little monitoring service thats solely based on pg_stat_statements data, ignoring IN list length would certainly be a good change.

We currently do this in post-processing, together with other data cleanup (e.g. ignoring the length of a VALUES list in an INSERT statement).

Given the fact that pgss data is normalized & you don't know which plan was chosen, I don't think distinguishing based on the length of the list helps anyone really.

I see pg_stat_statements as a high-level overview of which queries have run, and which ones you might want to look into closer using e.g. auto_explain.

Best,
Lukas

--
Lukas Fittl

Skype: lfittl
Phone: +1 415 321 0630

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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: pg_hba_lookup function to get all matching pg_hba.conf entries