Re: Mark/Restore and avoiding RandomAccess sorts

"Simon Riggs" <simon(at)2ndquadrant(dot)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