Re: track generic and custom plans in pg_stat_statements
От | Michael Paquier |
---|---|
Тема | Re: track generic and custom plans in pg_stat_statements |
Дата | |
Msg-id | aIcWKh8wK2GWFMFz@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 Fri, Jul 25, 2025 at 02:34:07PM -0500, Sami Imseih wrote: > Sami Imseih <samimseih@gmail.com> writes: >> I think Michael's got a point. As of HEAD there are seven different >> places that are setting this to PLAN_CACHE_NONE; who's to say that >> pg_stat_statements or some other extension might not wish to >> distinguish some of those sources? At the very least, user-submitted >> versus internally-generated queries might be an interesting >> distinction. I don't have a concrete proposal for a different >> categorization than what we've got, but it seems worth considering >> while we still have the flexibility to change it easily. > > Sure, I get it now, I think. An example is the cached plan from a sql > in a utility statement of a prepared statement, as an example. right? Attached is my counter-proposal, where I have settled down to four categories of PlannedStmt: - "standard" PlannedStmt, when going through the planner. - internally-generated "fake" PlannedStmt. - custom cache - generic cache We could decide if a few more of the internal "fake" ones are worth subdividing, but I am feeling that this is kind of OK to start with. If we want more granularity, I was wondering about some bits to be able to mix one or more of these categories, but they are all exclusive as far as I know. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: