Robert Haas <robertmh...@gmail.com> 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 you consider the costs of checking tuple visibility and the costs
involved in access to a shared buffer, it's possible that copying tuples
to a local materialization store would be a win for rescans in any case.
(Of course it's a lot easier to credit that concept when the store
doesn't spill to disk.) Given the basic bogosity of the costing rules
I wasn't eager to mess with it; in fact I think we deliberately tweaked
things in this area to prevent materialization, because otherwise the
planner *always* wanted to materialize and that didn't seem to be a win.
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
already.
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
