Re: PostrgeSQL vs oracle doing 1 million sqrts am I doing it wrong?
| От | Pavel Stehule |
|---|---|
| Тема | Re: PostrgeSQL vs oracle doing 1 million sqrts am I doing it wrong? |
| Дата | |
| Msg-id | CAFj8pRBQpNf8DQdQDfaUH=QP3qR1U4BznvwUBoE1vApbrWhM_w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: PostrgeSQL vs oracle doing 1 million sqrts am I doing it wrong? (Josh Berkus <josh@agliodbs.com>) |
| Список | pgsql-hackers |
2014-08-08 2:13 GMT+02:00 Josh Berkus <josh@agliodbs.com>:
On 08/07/2014 04:48 PM, Tom Lane wrote:Yeah, that's a weeks-long project for someone. And would require a lot
> 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.
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
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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: