Re: track generic and custom plans in pg_stat_statements
Вложения
В списке pgsql-hackers по дате отправления:
| От | Michael Paquier |
|---|---|
| Тема | Re: track generic and custom plans in pg_stat_statements |
| Дата | |
| Msg-id | aH7IPp_Hku02xHP2@paquier.xyz обсуждение |
| Ответ на | Re: track generic and custom plans in pg_stat_statements (Sami Imseih <samimseih@gmail.com>) |
| Ответы |
Re: track generic and custom plans in pg_stat_statements
Re: track generic and custom plans in pg_stat_statements |
| Список | pgsql-hackers |
On Mon, Jul 21, 2025 at 04:47:31PM -0500, Sami Imseih wrote: > Last week I published a v11 that adds a field to QueryDesc, but as I thought > about this more, how about we just add 2 bool fields in QueryDesc->estate > ( es_cached_plan and es_is_generic_plan ), a field in CachedPlan ( > is_generic_plan ) > and after ExecutorStart, and if we have a cplan, we set the > appropriate plan cache > mode value. I think it's better to confine these new fields in Estate > rather than > at a higher level like QueryDesc. See v12. Yes, I think that this is a much better idea to isolate the whole concept and let pgss grab these values. We have lived with such additions for monitoring in EState a few times already, see for example de3a2ea3b264 and 1d477a907e63 that are tainted with my fingerprints. -- Michael
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера