Re: Mark/Restore and avoiding RandomAccess sorts

On Wed, 2007-01-10 at 10:46 -0500, Tom Lane wrote:
> "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.

It would have required a full re-sort and then scroll through to the
point it had got to. Which was kindof expensive, but possible.

> 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.

OK, I'm happier with that anyway. Sounds straightforward now.

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