Re: Mark/Restore and avoiding RandomAccess sorts - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Mark/Restore and avoiding RandomAccess sorts
Date
Msg-id 1168443369.3951.380.camel@silverbirch.site
Whole thread Raw
In response to Re: Mark/Restore and avoiding RandomAccess sorts  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Mark/Restore and avoiding RandomAccess sorts  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, 2007-01-10 at 10:10 -0500, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.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




pgsql-hackers by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: ECPG regression test failures on Solaris 10/x86_64 with
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] COPY with no WAL, in certain circumstances