Re: Is it useful to record whether plans are generic or custom?

Atsushi Torikoshi <atorik@gmail.com>

From: Atsushi Torikoshi <atorik@gmail.com>
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Fujii Masao <masao.fujii@oss.nttdata.com>, legrand legrand <legrand_legrand@hotmail.com>, Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>
Date: 2020-06-04T08:04:36Z
Lists: pgsql-hackers

Attachments

On Mon, May 25, 2020 at 10:54 AM Atsushi Torikoshi <atorik@gmail.com> wrote:

> On Thu, May 21, 2020 at 5:10 PM Kyotaro Horiguchi <horikyota.ntt@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

>

Commits

  1. Add generic_plans and custom_plans fields into pg_prepared_statements.