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

On 2021/03/26 0:33, torikoshia wrote:
> On 2021-03-25 22:14, Fujii Masao wrote:
>> On 2021/03/23 16:32, torikoshia wrote:
>>> On 2021-03-05 17:47, Fujii Masao wrote:
>>>
>>> Thanks for your comments!
>>
>> Thanks for updating the patch!
>>
>> PostgreSQL Patch Tester reported that the patched version failed to be compiled
>> at Windows. Could you fix this issue?
>> https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.131238
>>
> 
> It seems PGDLLIMPORT was necessary..
> Attached a new one.

Thanks for updating the patch!

In my test, generic_calls for a utility command was not incremented
before PL/pgSQL function was executed. Maybe this is expected behavior.
But it was incremented after the function was executed. Is this a bug?
Please see the following example.

-------------------------------------------
SELECT pg_stat_statements_reset();
SET enable_seqscan TO on;
SELECT calls, generic_calls, query FROM pg_stat_statements WHERE query LIKE '%seqscan%';
CREATE OR REPLACE FUNCTION do_ckpt() RETURNS VOID AS $$
BEGIN
   EXECUTE 'CHECKPOINT';
END $$ LANGUAGE plpgsql;
SET enable_seqscan TO on;
SET enable_seqscan TO on;

-- SET commands were executed three times before do_ckpt() was called.
-- generic_calls for SET command is zero in this case.
SELECT calls, generic_calls, query FROM pg_stat_statements WHERE query LIKE '%seqscan%';

SELECT do_ckpt();
SET enable_seqscan TO on;
SET enable_seqscan TO on;
SET enable_seqscan TO on;

-- SET commands were executed additionally three times after do_ckpt() was called.
-- generic_calls for SET command is three in this case.
SELECT calls, generic_calls, query FROM pg_stat_statements WHERE query LIKE '%seqscan%';
-------------------------------------------

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION