Re: track generic and custom plans in pg_stat_statements
От | Sami Imseih |
---|---|
Тема | Re: track generic and custom plans in pg_stat_statements |
Дата | |
Msg-id | CAA5RZ0t4A4PVLHK5DPZWCsZvtviLf==PGG5eiy6Bm0DCpchHyQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: track generic and custom plans in pg_stat_statements (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: track generic and custom plans in pg_stat_statements
|
Список | pgsql-hackers |
> Sami Imseih <samimseih@gmail.com> writes: > >> Perhaps CachedPlanType is > >> misnamed, though, would it be more suited to name that as a sort of > >> "origin" or "source" field concept? We want to know which which > >> source we have retrieved a plan that a PlannedStmt refers to. > > > Hmm, I’m not sure I see this as an improvement. In my opinion, > > CachedPlanType is a clear name that describes its purpose. > > 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? I can see that being useful, If I understood that correctly. -- Sami
В списке pgsql-hackers по дате отправления: