On Sep4, 2014, at 20:50 , Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2014-09-04 20:31 GMT+02:00 Josh Berkus <josh@agliodbs.com>:
> * The ability to "compile" functions/procedures for faster execution.
>
> This point is more complex, because bottleneck is not in plpgsql - it is
> terrible fast against noncompiled pcode interpreted PL/SQL and it is
> comparable with PL/SQL - due different design. A expression evaluation is
> slower, partially due using a SQL expression interpret, partially due our
> arrays and strings are immutable, and any composition are slow.
That, in principle, is just an inlining problem, though. Say we translate
PL/pgSQL into LLVM bytecode in the simplest possible way by simply traversing
the parse tree, and emitting calls to the functions that the interpreter calls
now. Now, that alone wouldn't buy much, as you say. But if we additionally
compile (at least parts of) the executor machinery to LLVM bytecode too
(just once, while building postgres), the LLVM optimizer should in principle
be able to inline at least some of these calls, which *could* have considerable
benefit. The hard part would probably be to figure out how to inform the
executor which parts it may consider to be *constant* (i.e. what constitues
the execution *plan*) and which parts can change from one execution to the
next (i.e. the executor state).
In fact, such an approach would allow all expression evaluations to be
JITed - not only those appearing in PL/pgSQL functions but also in plain SQL.
> Cost of hidden IO cast is negative too. If we can change it, then we can
> increase a sped.
But the whole power of PL/pgSQL comes from the fact that it allows you to
use the full set of postgres data types and operatores, and that it seamlessly
integrated with SQL. Without that, PL/pgSQL is about as appealing as BASIC
as a programming language...
best regards,
Florian Pflug