On Thu, Sep 4, 2014 at 6:40 PM, Florian Pflug <f...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
