Re: PostrgeSQL vs oracle doing 1 million sqrts am I doing it wrong?

2014-08-08 2:13 GMT+02:00 Josh Berkus <josh(at)agliodbs(dot)com>:

> On 08/07/2014 04:48 PM, Tom Lane wrote:
> > plpgsql is not efficient at all about coercions performed as a side
> > effect of assignments; if memory serves, it always handles them by
> > converting to text and back. So basically the added cost here came
> > from float8out() and float4in(). There has been some talk of trying
> > to do such coercions via SQL casts, but nothing's been done for fear
> > of compatibility problems.
>
> Yeah, that's a weeks-long project for someone. And would require a lot
> of tests ...
>

It is not trivial task. There are two possible direction and both are not
trivial (I am not sure about practical benefits for users - maybe for some
PostGIS users - all for some trivial very synthetic benchmarks)

a) we can enhance plpgsql exec_assign_value to accept pointer to cache on
tupmap - it is relative invasive in plpgsql - and without benefits to other
PL

b) we can enhance SPI API to accept target TupDesc (with reusing
transformInsertRow) - it should be little bit less invasive in plpgsql, but
require change in SPI API. This path should be much more preferable - it
can be used in SQL/PSM and it can be used in lot of C extensions - It can
be more simply to specify expected TupDesc than enforce casting via
manipulation with SQL string. I missed this functionality more times. I
designed PL/pgPSM with same type strict level as PostgreSQL has - and this
functionality can simplify code.

PLpgSQL uses spi_prepare_params .. we can enhance this function or we can
introduce new spi_prepare_params_enforce_result_type

Regards

Pavel

>
> --
> Josh Berkus
> PostgreSQL Experts Inc.
> http://pgexperts.com
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>