Robert Haas writes:
> On Sep 6, 2009, at 10:45 AM, Tom Lane wrote:
>> ... But now that we have a plan for a less obviously broken costing
>> approach, maybe we should open the floodgates and allow
>> materialization
>> to be considered for any inner path that doesn't materialize itself
>> alrea
On Sep 6, 2009, at 10:45 AM, Tom Lane wrote:
Robert Haas writes:
And, by the way, is the algorithm proposed in the comment sensible
anyway? Under what circumstances would it make sense to
materialize a
sequential scan?
Expensive filter conditions, for example.
Ah, right. Yeah that co
Robert Haas writes:
> And, by the way, is the algorithm proposed in the comment sensible
> anyway? Under what circumstances would it make sense to materialize a
> sequential scan?
Expensive filter conditions, for example.
I've occasionally wondered if this code isn't outright wrong anyway:
when
On Sat, Sep 5, 2009 at 8:39 PM, Tom Lane wrote:
> I wrote:
>> It might be sufficient to have cost_nestloop just hardwire the knowledge
>> that certain inner path types have a different behavior here --- that
>> is, for a rescan there is zero start cost and some very low per-tuple
>> cost, independe
I wrote:
> It might be sufficient to have cost_nestloop just hardwire the knowledge
> that certain inner path types have a different behavior here --- that
> is, for a rescan there is zero start cost and some very low per-tuple
> cost, independent of the path's nominal cost values (which would now
Robert Haas writes:
> 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?
Yeah, probably.
On Fri, Sep 4, 2009 at 9:54 PM, Tom Lane wrote:
> Robert Haas 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
>> worktabl
Robert Haas 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 st
