Re: IDEA: pg_stat_statements tracking utility statements by tag?

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: IDEA: pg_stat_statements tracking utility statements by tag?
Дата
Msg-id 73f34fe1-4171-d8c6-778d-4f92935cbd88@oss.nttdata.com
обсуждение исходный текст
Ответ на IDEA: pg_stat_statements tracking utility statements by tag?  (Martijn van Oosterhout <kleptog@gmail.com>)
Ответы Re: IDEA: pg_stat_statements tracking utility statements by tag?  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers

On 2020/07/29 18:24, Martijn van Oosterhout wrote:
> Hoi hackers,
> 
> We've been using the pg_stat_statements extension to get an idea of the queries used in the database, but the table
isbeing filled with entries like:
 
> 
> SAVEPOINT sa_savepoint_NNN;
> RELEASE SAVEPOINT sa_savepoint_NNN;
> DECLARE "c_7f9451c4dcc0_5" CURSOR WITHOUT HOLD ...
> FETCH FORWARD 250 FROM "c_7f9451b03908_5"
> 
> Since the unique id is different for each query, the aggregation does nothing and there are quite a lot of these
drowningout the normal queries (yes, I'm aware this is an issue of itself). The only way to deal with this is
"pg_stat_statements.track_utility=off".However, it occurs to me that if you just tracked the tags rather than the full
querytext you could at least track the number of such queries and how much time they take. So the above queries would
betracked under SAVEPOINT, RELEASE, DECLARE CURSOR and (I guess) FETCH respectively. But it would also catch DDL.
 
> 
> Does this sound like something for which a patch would be accepted?

Or, we should extend the existing query normalization to handle also DDL?

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



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

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Should we remove a fallback promotion? take 2
Следующее
От: Robert Haas
Дата:
Сообщение: Re: recovering from "found xmin ... from before relfrozenxid ..."