"Simon Riggs" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate