Re: Is it useful to record whether plans are generic or custom?
torikoshia <torikoshia@oss.nttdata.com>
From: torikoshia <torikoshia@oss.nttdata.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: pgsql-hackers@postgresql.org, ikedamsh@oss.nttdata.com,
atorik@gmail.com, legrand_legrand@hotmail.com,
tatsuro.yamada.tf@nttcom.co.jp
Date: 2020-07-31T09:47:48Z
Lists: pgsql-hackers
Attachments
- 0002-POC-add-plan-type-to-pgss.patch (text/x-diff) patch 0002
On 2020-07-30 14:31, Fujii Masao wrote: > 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 Oops, sorry about that. I just fixed it there for now. >> >> 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, Regards, -- Atsushi Torikoshi NTT DATA CORPORATION
Commits
-
Add generic_plans and custom_plans fields into pg_prepared_statements.
- d05b172a760e 14.0 landed