Re: track generic and custom plans in pg_stat_statements
От | Michael Paquier |
---|---|
Тема | Re: track generic and custom plans in pg_stat_statements |
Дата | |
Msg-id | aIq0KgnwY_GW6IPC@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
|
Список | pgsql-hackers |
On Wed, Jul 30, 2025 at 03:09:08PM -0500, Sami Imseih wrote: >> In practice, with this knowledge, we can access the CachedPlanSource of >> the corresponding PREPARED statement via an extension and override the >> decision made in 'auto' mode. Unfortunately, we cannot obtain a pointer >> to plan cache entries for plans prepared by the extended protocol, but >> this may be possible in the future. >> >> So, I meant that the source of the plan is one important characteristic, >> and the type (custom or generic) is another, independent characteristic It seems to me that we're going to need a bit more than a design concept here, explaining how this can be useful for core to provide this knowledge to extensions. A lot of concepts can be defined as "useful", but it's hard to evaluate what you'd want here and how much it can be useful in terms of manipulations of the cached plans depending on what you may aim for. It's also unclear up to which extent the current state of the code would be able to help in the concepts you're describing. Anyway, I am not inclined to have pointer references in structures pointing to other parts of the system, just because these can be "useful". -- Michael
Вложения
В списке pgsql-hackers по дате отправления: