Re: [PROPOSAL] Detecting plan changes with plan_id in pg_stat_activity

Поиск
Список
Период
Сортировка
От Imseih (AWS), Sami
Тема Re: [PROPOSAL] Detecting plan changes with plan_id in pg_stat_activity
Дата
Msg-id 516E294A-A0EC-4998-9C3C-BBFCA6E679A5@amazon.com
обсуждение исходный текст
Ответ на Re: [PROPOSAL] Detecting plan changes with plan_id in pg_stat_activity  ("Imseih (AWS), Sami" <simseih@amazon.com>)
Ответы Re: [PROPOSAL] Detecting plan changes with plan_id in pg_stat_activity  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers
>    Good point. I will separate this patch.

I separated the pg_stat_statements patch. The patch
Introduces a secondary hash that tracks locations of
A query ( by queryid ) in the external file. The hash
remains in lockstep with the pgss_hash using a
synchronization routine. For the default
pg_stat_statements.max = 5000, this hash requires 2MB megabytes
of additional shared memory.

My testing does not show any regression for workloads
In which statements are not issues by multiple users/databases.

However, it shows good improvement, 10-15%, when there
are similar statements that are issues by multiple 
users/databases/tracking levels.

Besides this improvement, this will open up the opportunity
to also track plan_id's as discussed earlier in the thread.

Thanks for the feedback.

Regards, 

Sami Imseih
Amazon Web Services





Вложения

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

Предыдущее
От: Pavel Borisov
Дата:
Сообщение: Re: Use fadvise in wal replay
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Schema variables - new implementation for Postgres 15