Re: Mark/Restore and avoiding RandomAccess sorts

On Wed, 2007-01-10 at 10:10 -0500, Tom Lane wrote:
> "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> > Merge Joins require us to potentially Mark and Restore positions in the
> > tuples arriving from executor sub-nodes.
>
> I came across an old note to myself suggesting that we handle this by
> interposing a Materialize node, and then teaching Material that if it's
> told EXEC_FLAG_MARK but not EXEC_FLAG_REWIND or EXEC_FLAG_BACKWARD, it
> need keep data only as far back as the Mark position. So the structural
> requirements are mostly in place already, it's just a matter of figuring
> out a nice way to implement the "drop older parts of the tuplestore"
> business.

Same idea, I guess.

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.

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?

Anyway, not just yet.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com