Re: add_path() for Path without InitPlan: cost comparison vs. Paths that require one

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