Subject | Re: Call for ideas - CONNECT BY |
---|---|
Author | paulruizendaal |
Post date | 2004-04-03T07:54:33Z |
--- In Firebird-Architect@yahoogroups.com, "Dmitry Yemanov"
<dimitr@u...> wrote:
Thank you. The pipelined/tree-like structure of RSB's had escaped me
so far and I was already wondering how operations were combined. By
now I have set my mind on bringing clarity to this bit of engine code
and I will try to make it stand out better that RSE's are a pipeline
or operation tree, with a certain 'stacking order'.
Starting later today I'll be traveling for a week, so no quick
responses - but please keep the suggestions and explanations coming.
Paul
<dimitr@u...> wrote:
> Paul,Dmitry,
>
Thank you. The pipelined/tree-like structure of RSB's had escaped me
so far and I was already wondering how operations were combined. By
now I have set my mind on bringing clarity to this bit of engine code
and I will try to make it stand out better that RSE's are a pipeline
or operation tree, with a certain 'stacking order'.
Starting later today I'll be traveling for a week, so no quick
responses - but please keep the suggestions and explanations coming.
Paul
> From the higher levels POV, RSB is a cursor. It can be opened,fetched and
> closed. More precisely (from the implementation POV), RSB is afirst N
> transformation from one data stream to another. Lowest-level RSBs
> (rsb_sequential, rsb_indexed, rsb_navigate) are plain access types.
> rsb_boolean applies a filter to the input stream, rsb_skip removes
> rows from a stream via N dummy fetches, rsb_join merges two streamsinto one
> using the nested loops algorithm and so on. They are linked in achain by
> the optimizer to produce the wanted result. Their common parts are:(a) they
> share the same public interface and (b) they have K ( 0 <= K <inf ) input
> RSBs.
>
> Hope Jim will explain it better ;-)
>
>
> Dmitry