Adriano dos Santos Fernandes wrote:

> Em 9/2/2010 12:48, Jim Starkey escreveu:
>
>> Alexander Peshkoff wrote:
>>
>>
>>> On Tuesday 09 February 2010 05:40:02 Peter Faulks wrote:
>>>
>>>
>>>
>>>> Is blr here to stay?
>>>>
>>>>
>>>>
>>> yes
>>>
>>>
>>>
>> Why? It's obsolete. And it's a crutch that lets Firebird from pushing
>> SQL into the engine where it belongs.
>>
>>
> ...
>
>> The idea of BLR was to move the cost of language processing from runtime
>> to compilation time. It doesn't matter any more.
>>
> In my opinion, BLR is to SQL in Firebird what bytecode is to Java source
> in Java. I see not much sense in remove (from metadata) it. For adhoc
> queries, we'll be able (if desired) to run SQL without generate BLR.
>
> What I think is necessary is that BLR could be upgraded (when restoring
> a database) by the engine, so obsolete or changed functionality could be
> adapted.
>
> For example, there is current three set of aggregate functions BLR. One
> (blr_run_*) is not supported anymore. blr_agg_* is used. And blr_*
> (count, average, etc) is something that DSQL could not generate but is
> still supported in the engine.
>
>
>

It's a pity that the running aggregates got dropped. The ability to
print out a running count, running total, or running average was really
quite useful.

But back to BLR. The analogy to Java byte codes isn't off base, but BLR
doesn't provide the benefits of Java classes, which, primarily, is
portability. Firebird, Interbase, and Oracle Rdb are the only database
systems that every used BLR, and I doubt there is any compatibility
among these left. And since nothing but GPRE generates static BLR, the
language efficiency argument is long gone.

I invented BLR to pass open ended semantics between client and server in
a computationally efficient manner when the VAX 780 roamed the earth,
workstations maxed out at 3 MB, and servers at 7MB. That was a
different era. What made sense then, doesn't make sense now. What
makes sense now is caching compiled SQL statements and procedures of the
server, and paying to cost to prepare then on demand. By leaving the
engine BLR bound, you make this impossible. So by sticking to
tradition, you're accepting a performance (both elapsed and latency)
that your competitors don't have. And it's all self-induced.

What does make sense is to leave BLR in place for backwards
compatibility and move the SQL into the engine. If you can't figure out
how to do this, look at Vulcan. Moving SQL into the engine will reduce
code size and complexity, sidestep all sorts of nasty meta-data issues,
and speed up the product.

--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376



[Non-text portions of this message have been removed]