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
