Subject Re: [Firebird-Architect] GPRE
Author Adriano dos Santos Fernandes
Em 9/2/2010 13:55, Jim Starkey escreveu:
> 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.
>
For curiosity, what exactly they used to do?

> 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.
>
Are you sure no other database engine store some sort of (pre)compiled
command?

> 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.
>
But BLR is a (virtual) machine language. Only Firebird supports it, like
only PPC machine could run PPC instructions. :-)

What I agree is that would be more simple to have post-parsed node
hierarchy direct for engine needs than generate and parse BLR. But this
does not seems a very complicated thing currently.

> 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.
Since Firebird 2.5, SQL is already supported in the engine. For example,
when a database is created with a default character set and collation, a
DSQL command is internally (no y-valve) sent and run.


Adriano