Re: Transient plans versus the SPI API
От | Peter Eisentraut |
---|---|
Тема | Re: Transient plans versus the SPI API |
Дата | |
Msg-id | 1312481494.24208.13.camel@vanquo.pezone.net обсуждение исходный текст |
Ответ на | Transient plans versus the SPI API (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Transient plans versus the SPI API
|
Список | pgsql-hackers |
On tis, 2011-08-02 at 16:47 -0400, Tom Lane wrote: > The most straightforward way to reimplement things within spi.c would > be to redefine SPI_prepare as just doing the parse-and-rewrite steps, > with planning always postponed to SPI_execute. In the case where you > just prepare and then execute a SPIPlan, this would come out the same > or better, since we'd still just do one planning cycle, but the > planner could be given the actual parameter values to use. However, > if you SPI_prepare, SPI_saveplan, and then SPI_execute many times, you > might come out behind. This is of course the same tradeoff we are > going to impose at the SQL level anyway, but I wonder whether there > needs to be a control knob available to C code to retain the old > plan-once-and-always-use-that-plan approach. How about a new function like SPI_parse that has the new semantics? Note that the SPI functions are more or less directly exposed in PL/Perl and PL/Python, and there are a number of existing idioms there that make use of prepared plans. Changing the semantics of those functions might upset a lot of code.
В списке pgsql-hackers по дате отправления: