On 2020/07/22 16:49, torikoshia wrote:
> On 2020-07-20 13:57, torikoshia wrote:
>
>> As I proposed earlier in this thread, I'm now trying to add information
>> about generic/cudstom plan to pg_stat_statements.
>> I'll share the idea and the poc patch soon.
>
> Attached a poc patch.
Thanks for the POC patch!
With the patch, when I ran "CREATE EXTENSION pg_stat_statements",
I got the following error.
ERROR: function pg_stat_statements_reset(oid, oid, bigint) does not exist
>
> Main purpose is to decide (1) the user interface and (2) the
> way to get the plan type from pg_stat_statements.
>
> (1) the user interface
> I added a new boolean column 'generic_plan' to both
> pg_stat_statements view and the member of the hash key of
> pg_stat_statements.
>
> This is because as Legrand pointed out the feature seems
> useful under the condition of differentiating all the
> counters for a queryid using a generic plan and the one
> using a custom one.
I don't like this because this may double the number of entries in pgss.
Which means that the number of entries can more easily reach
pg_stat_statements.max and some entries will be discarded.
> I thought it might be preferable to make a GUC to enable
> or disable this feature, but changing the hash key makes
> it harder.
What happens if the server was running with this option enabled and then
restarted with the option disabled? Firstly two entries for the same query
were stored in pgss because the option was enabled. But when it's disabled
and the server is restarted, those two entries should be merged into one
at the startup of server? If so, that's problematic because it may take
a long time.
Therefore I think that it's better and simple to just expose the number of
times generic/custom plan was chosen for each query.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION