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