> 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.
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.
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.
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.