Hi Tom, > On 25 Jul 2019, at 14:25, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Please explain yourself. InitPlans will, as a rule, get stuck into the > same place in the plan tree regardless of which paths are chosen; that's > why we need not consider them in path cost comparisons.
Ah that’s true. I didn’t realise that at the time I wrote. But I think my problem is still real... > Moreover, once > the initplan's own subplan is determined, it's going to be the same > regardless of the shape of the outer query --- Yes that’s true too. > so if we did factor it > in, it'd contribute the same cost to every outer path, and thus it > still wouldn't change any decisions. I think I’m exposed to the problem because I’m changing how certain queries are fulfilled. And in the case of a RECURSIVE CTE, the plan ends up being an InitPlan that materializes the CTE, and then a scan of that materialized result. The problem is that I can fulfil the entire query with a scan against an MV table. Point is it’s an alternative that achieves both the InitPlan (because it’s unnecessary) and the final scan. But the cost comparison during add_path() is only taking into account the cost of the final scan, which is so cheap that it is preferable even to a simple scan of an MV. > So I don't follow what you're > on about here. Hmm. Having written the above, I realise I’m not clear on why my extension isn’t offered the opportunity to materialise the work table for the InitPlan. Sorry. I should have thought about that question first. It might just be an error in my code. I’ll follow up with an answer. > > regards, tom lane
