On Sep4, 2014, at 20:50 , Pavel Stehule <pavel.steh...@gmail.com> wrote: > 2014-09-04 20:31 GMT+02:00 Josh Berkus <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers