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

Поиск
Список
Период
Сортировка
От Atsushi Torikoshi
Тема Re: Is it useful to record whether plans are generic or custom?
Дата
Msg-id CACZ0uYHwomcmVHj4+gQkf_CqEgoXt=qgG=frTnAJevCf=Ocavw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Is it useful to record whether plans are generic or custom?  (Atsushi Torikoshi <atorik@gmail.com>)
Ответы Re: Is it useful to record whether plans are generic or custom?  (Masahiro Ikeda <ikedamsh@oss.nttdata.com>)
Список pgsql-hackers
Дерево обсуждения
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
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Juan Fuentes
Дата:
Сообщение: Possible bug on Postgres 12 (CASE THEN evaluated prematurely) -Change of behaviour compared to 11, 10, 9
Следующее
От: Dilip Kumar
Дата:
Сообщение: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions