Re: match_unsorted_outer() vs. cost_nestloop()

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
> be defined as always the costs for the first scan).  And maybe the same
> in cost_mergejoin.  Offhand I don't think anyplace else really needs to
> think about rescan costs.

After thinking about that a bit more, I think the best way might be
to create a "cost_rescan" function that is given a Path and returns
the startup cost and total cost to be assumed for a rescan of this Path.
It would know about the special behavior of MaterialPath and the other
tuplestore-using plan types, and for everything else would just return
the path's regular costs.

Alternatively we could create a cost_foo_rescan() function paralleling
each cost_foo() function, but given the small number of distinct
behaviors I think that would be fairly redundant and hard to maintain.
        regards, tom lane