Subject | Re: [Firebird-Architect] Re: hadoopdb parallel database |
---|---|
Author | Ann W. Harrison |
Post date | 2009-09-11T18:04:56Z |
paulruizendaal wrote:
interface between the compile/optimize code and the execution time
code. Then RSB's (record source blocks can be sent to engines as
appropriate.
BLR was designed to represent different interface languages -
SQL had not become synonymous with relational - and to be largely
architecture independent. The model was intelligent front end
tools, higher level than Delphi, that generated requests to the
database in BLR. BLR is not an optimal interface within the
engine.
The split between lex/parse/compile/optimize and execution is
similar to the MySQL storage engine interface. It loses all the
intelligence that might exist in the lower level - which doesn't
matter if both halves come from Firebird.
Cheers,
Ann
>Another - and probably better - approach would be to formalize the
> I'm not sure the blr API still exists in FB head, but if it
> does the Scimore design could be done by taking the SQL compiler &
> optimiser, breaking it out to a separate binary and enhancing it
> to do the automated sharding, replication, etc. and send appropriate
> blr to each node in the tree.
>
interface between the compile/optimize code and the execution time
code. Then RSB's (record source blocks can be sent to engines as
appropriate.
BLR was designed to represent different interface languages -
SQL had not become synonymous with relational - and to be largely
architecture independent. The model was intelligent front end
tools, higher level than Delphi, that generated requests to the
database in BLR. BLR is not an optimal interface within the
engine.
The split between lex/parse/compile/optimize and execution is
similar to the MySQL storage engine interface. It loses all the
intelligence that might exist in the lower level - which doesn't
matter if both halves come from Firebird.
Cheers,
Ann