Robert Haas <robertmh...@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 ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
