Re: track generic and custom plans in pg_stat_statements - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: track generic and custom plans in pg_stat_statements
Date
Msg-id CAA5RZ0s=K+CvM6dZcYnvzitsU0g7btDjRpVjOU8PAh8PP=zX5w@mail.gmail.com
Whole thread Raw
In response to Re: track generic and custom plans in pg_stat_statements  (Andrei Lepikhov <lepihov@gmail.com>)
Responses Re: track generic and custom plans in pg_stat_statements
List pgsql-hackers

> with the types of cached plan. We need to be able to differentiate
> when cached plans are not used, so a simple boolean is not
> sufficient.
Sure. But I modestly hope you would add a CachedPlanSource pointer
solely to the PlannedStmt and restructure it a little as we discussed
above. And no new structures are needed. Am I wrong?

That was my initial intention somehow to get CachedPlan available 
to Executor hooks. But, as you pointed out there is more value in 
CachedPlanSource. 

I know Michael opposed the idea of  carrying these structures,
at least CachedPlan, to Executor hooks ( or maybe just not QueryDesc?? ). 
It will be good to see what he think, or if others an opinion about this, about 
adding a pointer to CachedPlanSource in PlannedStmt vs setting a flag in 
PlannedStmt to track plan cache type for the current execution? The former
does provide more capability for extensions, as Andrei has pointed out 
earlier.


--
Sami 

pgsql-hackers by date:

Previous
From: Andrei Lepikhov
Date:
Subject: Re: track generic and custom plans in pg_stat_statements
Next
From: Peter Geoghegan
Date:
Subject: Re: index prefetching