Re: Planning counters in pg_stat_statements (using pgss_store)

Поиск
Список
Период
Сортировка
От Andy Fan
Тема Re: Planning counters in pg_stat_statements (using pgss_store)
Дата
Msg-id CAKU4AWq=S+4F=Q=O8-FHXEURJEmDQ8-1tX8d1sfghn7OFHhMbg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Planning counters in pg_stat_statements (using pgss_store)  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Ответы Re: Planning counters in pg_stat_statements (using pgss_store)  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers
Thanks for the excellent extension. I want to add 5 more fields to satisfy the
following requirements.

int   subplan; /* No. of subplan in this query */
int   subquery; /* No. of subquery */
int   joincnt; /* How many relations are joined */
bool hasagg; /* if we have agg function in this query */
bool hasgroup; /* has group clause */


1. Usually I want to check total_exec_time / rows to see if the query is missing
   index, however aggregation/groupby case makes this rule doesn't work. so
   hasagg/hasgroup should be a good rule to filter out these queries.

2. subplan is also a important clue to find out the query to turning. when we
   check the slow queries with pg_stat_statements, such information maybe
   helpful as well.

3. As for subquery / joincnt,  actually it is just helpful for optimizer
   developer to understand the query character is running most, it doesn't help
   much for user.


The attached is a PoC, that is far from perfect since 1). It maintain a
per-backend global variable query_character which is only used in
pg_stat_statements extension.  2). The 5 fields is impossible to change no
matter how many times it runs, so it can't be treat as Counter in nature.
However I don't think the above 2 will cause big issues.

I added the columns to V1_8 rather than adding a new version. this can be
changed at final patch.

Any suggestions?


Best Regards
Andy Fan
Вложения

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

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: factorial function/phase out postfix operators?
Следующее
От: "Jonathan S. Katz"
Дата:
Сообщение: PostgreSQL 13 Beta 1 Release Announcement Draft