5 ms·

Especially when PL/V8 seems natural when working on JSON(b). It even is much faster compared to PL/pgSQL (at least in a project I've been working on lately).

• s_kilk 11y ago
  > It even is much faster compared to PL/pgSQL (at least in a project I've been working on lately) That's good to hear. At the time I had read somewhere that PL/V8 can be slow because it needs to cast/convert data back and forth between javascript and native Postgres representations. It's possible that that assessment is wrong, however.
  • alfanick 11y ago
    Ofc make your own benchmarks before taking PLV8 into consideration. In my case PL/pgSQL FOR loop was particularly slow; lack of builtin data structures like map or stack (though stack is emulated in V8 via array) caused performance problems – array operations are really slow in PL/pgSQL (compared to V8), instead of using map I've use indexed temporary table (creation of such is quite costly). Still you might have a point here – PL/pgSQL stores execution plans with the function, so there is a chance of being more efficient here.
    • baudehlo 11y ago
      Did you try using plain SQL with unnest()?
  • jerrysievert 11y ago
    PL/V8 maintainer here - yes, JSON/JSONB structures are brought through the C++/Javascript membrane, but for the most part it doesn't seem too slow (full disclosure, i wrote a mongo clone on PL/V8 a few years ago). but, there is also the ability to simply query from inside a function using plv8.execute(), which gives you the ability to use JSONB operators, which are much faster.