Re: [HACKERS] Mark/Restore and avoiding RandomAccess sorts

2007-01-10 Thread Simon Riggs
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 alre

Re: [HACKERS] Mark/Restore and avoiding RandomAccess sorts

2007-01-10 Thread Tom Lane
"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

Re: [HACKERS] Mark/Restore and avoiding RandomAccess sorts

2007-01-10 Thread Simon Riggs
On Wed, 2007-01-10 at 10:10 -0500, Tom Lane wrote: > "Simon Riggs" <[EMAIL PROTECTED]> 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 > interp

Re: [HACKERS] Mark/Restore and avoiding RandomAccess sorts

2007-01-10 Thread Tom Lane
"Simon Riggs" <[EMAIL PROTECTED]> 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

Re: [HACKERS] Mark/Restore and avoiding RandomAccess sorts

2007-01-09 Thread Bruce Momjian
Simon Riggs wrote: > On Sat, 2007-01-06 at 17:06 -0500, Bruce Momjian wrote: > > I saw no replies to this. > > Me neither. > > I take it that means its a very good idea and we should add a TODO Added to TODO: * Improve merge join performance by allowing mark/restore of tuple sources http:/

Re: [HACKERS] Mark/Restore and avoiding RandomAccess sorts

2007-01-08 Thread Jim C. Nasby
On Mon, Jan 08, 2007 at 10:37:25AM +, Heikki Linnakangas wrote: > >Simon Riggs wrote: > >>Implementing the variable mark/restore buffer as a dumb Tuplestore would > >>mean that the space usage of the Sort could in worst case go as high as > >>x2 total space. The worst case is where the inner sc

Re: [HACKERS] Mark/Restore and avoiding RandomAccess sorts

2007-01-08 Thread Heikki Linnakangas
Bruce Momjian wrote: I saw no replies to this. Sounds like a good idea to me. (further comments below) Simon Riggs wrote: Implementing the variable mark/restore buffer as a dumb Tuplestore would mean that the space usage of the Sort could in worst case go as high as x2 total space. The wors

Re: [HACKERS] Mark/Restore and avoiding RandomAccess sorts

2007-01-07 Thread Simon Riggs
On Sat, 2007-01-06 at 17:06 -0500, Bruce Momjian wrote: > I saw no replies to this. Me neither. I take it that means its a very good idea and we should add a TODO -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)-

Re: [HACKERS] Mark/Restore and avoiding RandomAccess sorts

2007-01-06 Thread Bruce Momjian
I saw no replies to this. --- Simon Riggs wrote: > Merge Joins require us to potentially Mark and Restore positions in the > tuples arriving from executor sub-nodes. > > This currently means that if the tuples arrive from a