Re: Transient plans versus the SPI API

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.

In response to

Responses

Browse pgsql-hackers by date

  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