On Thu, Mar 26, 2026 at 3:52 PM Lukas Fittl <[email protected]> wrote: > That said, reflecting on the change, I wonder if its odd that we're > copying a string pointer instead of making an actual string copy. I > think that's probably okay in practice?
Normally, all of planning happens in the same memory context. Under GEQO, joins are planned in shorter-lived contexts that are reset, but I don't think a new PlannerInfo can get created in one of those short-lived contexts. At any rate, there's no point in having two copies of the same string in the same memory context. > I'm still 50/50 on the naming here, since we have the alternative sub > plan that has an "alternative plan name" that's not that of the > alternative itself, but rather the base plan that was utilized. But I > see your concern regarding the naming being confusing in terms of what > the "original" or "base" would actually refer to. I've also considered > whether something like "alternative_plan_group" could make sense > (since all alternative sub plans will have the same value), but maybe > that conveys too much intent on what this is used for. Let's go with this for now, and if a consensus emerges that I got it wrong, we can always change it. > That said, I think for now, to get the buildfarm happy again, v23/0001 > seems good. > > v23/0002 also looks good. Thanks. Committed. Nothing has obviously broken so far, BUT even machines like skink that were failing weren't failing on every run, so it may be a while before we get a clear view of the situation -- unless of course this didn't fix it or even made things worse, in which case we might find out a lot faster. Hopefully not, but then I thought this was going to work the first time. In the meanwhile, we should try to make a decision on what to do about pg_collect_advice and pg_stash_advice. -- Robert Haas EDB: http://www.enterprisedb.com
