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

From: torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>
To: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, tatsuro(dot)yamada(dot)tf(at)nttcom(dot)co(dot)jp, sunchengxi(at)highgo(dot)com, pgsql-hackers(at)postgresql(dot)org, pavel(dot)stehule(at)gmail(dot)com, legrand_legrand(at)hotmail(dot)com
Subject: Re: Is it useful to record whether plans are generic or custom?
Date: 2021-03-23 07:32:40
Message-ID: e49b70b166449f979383e78d93cea6b8@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021-03-05 17:47, Fujii Masao wrote:

Thanks for your comments!

> I just tried this feature. When I set plan_cache_mode to
> force_generic_plan
> and executed the following queries, I found that
> pg_stat_statements.generic_calls
> and pg_prepared_statements.generic_plans were not the same.
> Is this behavior expected? I was thinking that they are basically the
> same.

It's not expected behavior, fixed.

>
> DEALLOCATE ALL;
> SELECT pg_stat_statements_reset();
> PREPARE hoge AS SELECT * FROM pgbench_accounts WHERE aid = $1;
> EXECUTE hoge(1);
> EXECUTE hoge(1);
> EXECUTE hoge(1);
>
> SELECT generic_plans, statement FROM pg_prepared_statements WHERE
> statement LIKE '%hoge%';
> generic_plans | statement
> ---------------+----------------------------------------------------------------
> 3 | PREPARE hoge AS SELECT * FROM pgbench_accounts WHERE
> aid = $1;
>
> SELECT calls, generic_calls, query FROM pg_stat_statements WHERE query
> LIKE '%hoge%';
> calls | generic_calls | query
> -------+---------------+---------------------------------------------------------------
> 3 | 2 | PREPARE hoge AS SELECT * FROM
> pgbench_accounts WHERE aid = $1
>
>
>
>
> When I executed the prepared statements via EXPLAIN ANALYZE, I found
> pg_stat_statements.generic_calls was not incremented. Is this behavior
> expected?
> Or we should count generic_calls even when executing the queries via
> ProcessUtility()?

I think prepared statements via EXPLAIN ANALYZE also should be counted
for consistency with pg_prepared_statements.

Since ActivePortal did not keep the plan type in the
ProcessUtility_hook,
I moved the global variables 'is_plan_type_generic' and
'is_prev_plan_type_generic' from pg_stat_statements to plancache.c.

>
> DEALLOCATE ALL;
> SELECT pg_stat_statements_reset();
> PREPARE hoge AS SELECT * FROM pgbench_accounts WHERE aid = $1;
> EXPLAIN ANALYZE EXECUTE hoge(1);
> EXPLAIN ANALYZE EXECUTE hoge(1);
> EXPLAIN ANALYZE EXECUTE hoge(1);
>
> SELECT generic_plans, statement FROM pg_prepared_statements WHERE
> statement LIKE '%hoge%';
> generic_plans | statement
> ---------------+----------------------------------------------------------------
> 3 | PREPARE hoge AS SELECT * FROM pgbench_accounts WHERE
> aid = $1;
>
> SELECT calls, generic_calls, query FROM pg_stat_statements WHERE query
> LIKE '%hoge%';
> calls | generic_calls | query
> -------+---------------+---------------------------------------------------------------
> 3 | 0 | PREPARE hoge AS SELECT * FROM
> pgbench_accounts WHERE aid = $1
> 3 | 0 | EXPLAIN ANALYZE EXECUTE hoge(1)
>
>

Regards,

Attachment Content-Type Size
v6-0001-add-plan-type-to-pgss.patch text/x-diff 9.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey V. Lepikhov 2021-03-23 07:54:57 Re: Global snapshots
Previous Message Michael Paquier 2021-03-23 07:12:01 Re: [CLOBBER_CACHE]Server crashed with segfault 11 while executing clusterdb