Re: match_unsorted_outer() vs. cost_nestloop()

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> In joinpath.c, match_unsorted_outer() considers materializing the
> inner side of each nested loop if the inner path is not an index scan,
> bitmap heap scan, tid scan, material path, function scan, CTE scan, or
> worktable scan. In costsize.c, cost_nestloop() charges the startup
> cost only once if the inner path is a hash path or material path;
> otherwise, it charges it for every anticipated rescan.

> It seems to me, perhaps naively, like the criteria used in these two
> places are more different than they maybe should be.

They are considering totally different effects, so I'm not sure I
follow that conclusion.

I'll certainly concede that the costing of materialize plans is rather
bogus --- it's been a long time since materialize behaved the way
cost_material thinks it does (ie, read the whole input before handing
anything back). But our cost model doesn't have a way to represent the
true value of a materialize node, which is that a re-read is a lot
cheaper than the original fetch. I've occasionally tried to think of a
way to deal with that without introducing a lot of extra calculations
and complexity everywhere else ...

regards, tom lane