On Sat, Feb 15, 2025 at 10:29:41AM +0100, Andrei Lepikhov wrote: > I have already implemented it twice in different ways as a core patch. > In my projects, we need to track queryId and plan node ID for two reasons:
Are these available in the public somewhere or is that simply what Sami is proposing? > 1. Optimisational decisions made during transformation/path generation > stages up to the end of execution to correct them in the future. > 2. Cache information about the query tree/node state to use it for > statistical purposes. Gathering of statistical data based on a node tree is one reason, where it may or may not be required to walk through a path. Influencing the plan used with an already-generated one (where hints could be used) was the second one, mostly replacing a plan in the planner hook. Influencing the paths in a plan or a subplan didn't really matter much with hints to drive the paths. > In my experience, we don't need a single plan_id field; we just need an > 'extended list' pointer at the end of the Plan, PlannedStmt, Query, and > RelOptInfo structures and a hook at the end of the create_plan_recurse() to > allow passing some info from the path generator to the plan tree. > An extension may add its data to the list (we may register an extensible > node type to be sure we don't interfere with other extensions) and > manipulate it in a custom way and with custom UI. > Generally, it makes the optimiser internals more open to extensions. Sounds to me that this maps with the addition of a "private" area to some of the plan structures to allow extensions to attach some data that would be reused elsewhere, which is rather independent than what's suggested here? These kinds of private areas could be to a list, or even a different structure, depending on your extension design. -- Michael
signature.asc
Description: PGP signature
