Hi Tom,
> On 25 Jul 2019, at 14:25, Tom Lane <tgl@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
thatmaterialized 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
achievesboth 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
thatit 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
thework 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