Cost numbers would look better if it is cooked a bit. Is it worth being in core?
I didn't come up with ideas about how to use them.
IMHO they might not so necessary..
Perhaps plan_generation is not needed there.
+1.
Now 'calls' is sufficient and 'plan_generation' may confuse users.
BTW, considering 'calls' in pg_stat_statements is the number of times
statements were EXECUTED and 'plans' is the number of times
statements were PLANNED, how about substituting 'calls' for 'plans'?
I've modified the above points and also exposed the numbers of each generic plans and custom plans.
I'm now a little bit worried about the below change which removed the overflow checking for num_custom_plans, which was introduced in 0001-Expose-counters-of-plancache-to-pg_prepared_statement.patch, but I've left it because the maximum of int64 seems enough large for counters. Also referencing other counters in pg_stat_user_tables, they don't seem to care about it.
```
- /* Accumulate total costs of custom plans, but 'ware overflow */ - if (plansource->num_custom_plans < INT_MAX) - { - plansource->total_custom_cost += cached_plan_cost(plan, true); - plansource->num_custom_plans++; - }
