On Mon, May 25, 2020 at 10:54 AM Atsushi Torikoshi <ato...@gmail.com> wrote:
> On Thu, May 21, 2020 at 5:10 PM Kyotaro Horiguchi <horikyota....@gmail.com>
> wrote:
>
>> 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++;
- }
```
Regards,
Atsushi Torikoshi
>
0003-Expose-counters-of-plancache-to-pg_prepared_statement.patch
Description: Binary data
