Hi
> Please, don't send screenshots - we believe you :-) > > Your code can be little bit faster if you use flag IMMUTABLE > > There were more patches that reduced the overhead of expression's > evaluation in PL/pgSQL. > > History > > https://github.com/postgres/postgres/commits/master/src/pl/plpgsql/src/pl_exec.c > > Some interesting commits > > https://github.com/postgres/postgres/commit/8f59f6b9c0376173a072e4fb7de1edd6a26e6b52 > > https://github.com/postgres/postgres/commit/fbc7a716084ebccd2a996cc415187c269ea54b3e > > https://github.com/postgres/postgres/commit/73b06cf893c9d3bb38c11878a12cc29407e78b6c > > Originally, PL/pgSQL was designed as glue of SQL and the expression > evaluation was not too good. It was significantly slower in expression's > evaluation than other interpreters like Perl or Python. > > But lot of people uses PL/pgSQL for numeric calculations with PostGIS, so > speed of expression's evaluation is more important than before, and after > all optimizations, although the PL/pgSQL is still slower than generic > interprets - still PL/pgSQL should be used mainly like glue of SQL, the > difference is significantly less - from 10x times slower to 2 slower. Still > there is not any JIT - so the performance is almost good I think. > still there is a lot of overhead there - in profiler the overhead of multiplication is less than 1%. But for significant improvements it needs some form of JIT (Postgres has JIT for SQL expressions, but it is not used for PLpgSQL expressions). On second hand, PL/pgSQL is not designed (and usually) not used for extensive numeric calculations like this. But if somebody try to enhance performance, (s)he will be welcome every time (I think so there is some space for 2x better performance - but it requires JIT). Regards Pavel > Regards > > Pavel > >
