The general match function

select 'Preliminary match',self.rowid,self.key,self.link
from self,other where

(self.rowid >= self.start)
and (self.rowid < self.end) (other.rowid >= other.start)
and (other.rowid < other.end) and (self.link == other.link) and (self.key == other.key); union select 'New subquery',... from self,other where (self.rowid >= self.start)
and (self.rowid < self.end) (other.rowid >= other.start)
and (other.rowid < other.end)
and ((self.link == '(' ) or (other.link == '(');

The machine executes this very inefficient general match function when both tables are triple format. G manages and filters the row output according to lighter weight match and select modifiers. The beginning and end points are known because both tables are nested triples with the forward pointers. Inefficiency when matches for terminated descents continue to report. But the counters move forward so the machine can keep the accumulated match results and knows when to reject failed descents.

When the 'New sub query' is returned, G will simply open a frame and repeat the same query, allowing it to terminate before re-stepping the prior query. This same format can also report any lighter weight link operators appear.

What are the row limits on the subquery?
I know that because I have the node of last valid matc (we filter extraneous matches). So the table opening the new query and the opposing table both have updated sub segment pointers. So the machine need merely launched the new frames with a duplicated copy of the master select. The binding of the limits is automatic, reference to the frame.

Triple form makes it easy because the sql can actually detect something other than canonical set and descent operators. The forward looking grammar means the machine can accumulate the match function defined by lighter weight operators.


Later, the sql sequences can get a bit smarter and faster, but for now this works in version 2.