On Thu, Sep 4, 2014 at 6:40 PM, Florian Pflug <fgp@phlo.org> wrote:
>> 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...
Right, and it's exactly those types and operators that are the cause
of the performance issues. A compiled pl/pgsql would only get serious
benefit for scenarios involving tons of heavy iteration or funky local
data structure manipulation. Those scenarios are somewhat rare in
practice for database applications and often better handled in a
another pl should they happen.
plv8 is emerging as the best "non-sql" it's JIT compiled by the plv8
runtime, the javascript language is designed for embedding. and the
json data structure has nice similarities with postgres's arrays and
types. In fact, if I *were* to attempt pl/pgsql compiling, I'd
probably translate the code to plv8 and hand it off to the llvm
engine. You'd still have to let postgres handle most of the operator
and cast operations but you could pull some things into the plv8
engine. Probably, this would be a net loser since plv8 (unlike
plpgsql) has to run everything through SPI.
IMO, what needs to happen first would be for the data type routines to
be pulled out of main library so that client side applications and pls
could link against it allowing for guaranteed sql semantics without
having to call into the backend -- at least the standard types.
merlin
