Arthur Zakirov wrote on 2018-03-09: > I'd like to review the patch and leave a feedback. I tested it with > different indexes on same table and with same queries and it works fine.
Thanks for taking some time to review my patch, Arthur! > First of all, GUC variables and functions. How about union > 'pg_stat_statements.good_plan_enable' and > 'pg_stat_statements.bad_plan_enable' into > 'pg_stat_statements.track_plan' with GUC_LIST_INPUT flag? It may accept > comma separated values 'good' and 'bad'. It lets to add another tracking > type in future without adding new variable. This sounds like a good idea to me; Somebody already suggested that tracking an "average plan" would be interesting as well, however I don't have any clever ideas on how to identify such a plan. > In same manner pg_stat_statements_good_plan_reset() and > pg_stat_statements_bad_plan_reset() functions can be combined in > function: > pg_stat_statements_plan_reset(in queryid bigint, in good boolean, in bad > boolean) This is also sensible, however if any more kinds of plans would be added in the future, there would be a lot of flags in this function. I think having varying amounts of flags (between extension versions) as arguments to the function also makes any upgrade paths difficult. Thinking more about this, we could also user function overloading to avoid this. An alternative would be to have the caller pass the type of plan he wants to reset. Omitting the type would result in the deletion of all plans, maybe? pg_stat_statements_plan_reset(in queryid bigint, in plan_type text) I'm not sure if there are any better ways to do this? > Further comments on the code. You're right about all of those, thanks!
