Re: match_unsorted_outer() vs. cost_nestloop() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: match_unsorted_outer() vs. cost_nestloop()
Date
Msg-id 23140.1252248309@sss.pgh.pa.us
Whole thread Raw
In response to Re: match_unsorted_outer() vs. cost_nestloop()  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: match_unsorted_outer() vs. cost_nestloop()
List pgsql-hackers
Robert Haas <robertmhaas@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


pgsql-hackers by date:

Previous
From: Kristian Larsson
Date:
Subject: Re: 8.5 release timetable, again
Next
From: Tom Lane
Date:
Subject: Re: Time zone abbreviations fix