From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Transient plans versus the SPI API |
Date: | 2011-08-04 18:11:34 |
Message-ID: | 1312481494.24208.13.camel@vanquo.pezone.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2011-08-04 18:26:15 | Re: psql: bogus descriptions displayed by \d+ |
Previous Message | Robert Haas | 2011-08-04 18:04:53 | Re: patch: move dumpUserConfig call in dumpRoles function of pg_dumpall.c |