On Fri, Sep 4, 2009 at 9:54 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.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
