On 24/7/2025 09:03, Michael Paquier wrote: > On Wed, Jul 23, 2025 at 12:15:06PM +0900, Michael Paquier wrote: >> A small thing that would be cleaner is to split the patch into two >> parts: one for the in-core backend addition and a second for PGSS. >> Code paths are different, so it's simple to do. > > I have been looking at the backend part of the change to add the > cached plan type to PlannedStmt, and found the concept clean. I have > moved the definition of the new enum to plannodes.h, tweaked a couple > of comments and the result seemed OK, so applied this part. I see you have chosen a variant with a new enum instead of a pointer to a plan cache entry. I wonder if you could write the arguments supporting this choice?
Currently, we are unable to track specific queries and analyse how planning decisions affect their execution. IMO, this is a missed opportunity, as even an extension-based feedback system could pave the way for developments in self-tuning DBMS. Plan cache entries seem to be the most suitable target for this purpose, as they usually refer to a long-lived statement and already contain some valuable data. -- regards, Andrei Lepikhov
