On Wed, 2007-01-10 at 10:46 -0500, Tom Lane wrote: > "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.
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 ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
