"Simon Riggs" <simon@2ndquadrant.com> writes:
> Presumably we'd need to teach the Materialize node to pass straight
> through when the node does not receive any of EXEC_FLAG_MARK,
> EXEC_FLAG_REWIND or EXEC_FLAG_BACKWARD.
It does that already.
> The Materialize node would have to communicate with the Sort node so it
> could indicate when it had passed its max size limit, so the Sort could
> complete the final merge in-situ without wasting more space. Would it be
> ugly to have the Materialize poke into the SortState?
I don't think this is workable; tuplesort is not designed to change from
on-the-fly merge to not-on-the-fly on-the-fly. IIRC it's throwing away
data as it goes in the first case, and you can't magically get it back.
Changing this seems like a case of adding 90% more complexity to buy 10%
more performance. It's already true that the planner avoids mergejoin
when there are lots of duplicate inner tuples, so I do not think we need
put lots of effort into performance improvements for the case of large
distances back to the mark. Teaching Material how to handle a small
mark distance cheaply should be sufficient.
regards, tom lane
