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(at)sss(dot)pgh(dot)pa(dot)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