Re: match_unsorted_outer() vs. cost_nestloop()

On Fri, Sep 4, 2009 at 9:54 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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 ...

I noticed that, too, and I don't know what to do about it either.

I guess my point is that for node types that dump their output into a
tuplestore anyway, it doesn't seem like cost_nestloop() should charge
n * the startup cost. I believe that at least function, CTE, and
worktable scans fall into this category. No?

...Robert