Re: track generic and custom plans in pg_stat_statements
От | Sami Imseih |
---|---|
Тема | Re: track generic and custom plans in pg_stat_statements |
Дата | |
Msg-id | CAA5RZ0tA43qf1HF1g6oYUGNBGFr23F29pf4F9Hymp2z8PyTsPg@mail.gmail.com обсуждение исходный текст |
Ответ на | 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 |
> > It may be more efficient to set the is_generic_plan option at the top > > plan node (PlannedStmt) and reference it wherever necessary. To identify > > a cached plan, we may consider pushing the CachedPlan/CachedPlanSource > > pointer down throughout pg_plan_query and maintaining a reference to the > > plan (or simply setting a boolean flag) at the same location — inside > > the PlannedStmt. > > We will need a field to store an enum. let's call it CachedPlanType > with the types of cached plan. We need to be able to differentiate > when cached plans are not used, so a simple boolean is not > sufficient. > ``` > typedef enum CachedPlanType > { > PLAN_CACHE_NOT_SET, /* Not a cached plan */ > PLAN_CACHE_GENERIC, /* Generic cached plan */ > PLAN_CACHE_CUSTOM, /* Custom cached plan */ > } CachedPlanType; > ``` > We can track a field for this enum in PlannedStmt and initialize > it to PLAN_CACHE_NOT_SET whenever we makeNode(PlannedStmt). > In GetCachedPlan, we iterate through plan->stmt_list to set the > value for the PlannedStmt. > > CachedPlanType will have to be defined in nodes.h for this to work. > > We can avoid the struct altogether and define the new PlannedStmt > field as an "int" and bit-pack the types. > > I prefer the CachedPlanType struct to do this, as it's cleaner and > self-documenting. v13 is the implementation using PlannedStmt as described above. -- Sami
Вложения
В списке pgsql-hackers по дате отправления: