Re: Transient plans versus the SPI API

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <pgsql-hackers(at)postgreSQL(dot)org>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Transient plans versus the SPI API
Date: 2011-08-02 21:03:21
Message-ID: 4E381FC9020000250003F9BF@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.
>
> Anyone have an opinion about that?

I have a few places I've used SPI_saveplan where there is really
only one sensible plan, so I'm pretty sure it would be a loss to use
the new technique in those places. Now, whether that would be a
loss that would be big enough for anyone to notice (or even to
reliably measure) is another question. It wouldn't surprise me if
the difference was insignificant, but it would be reassuring to have
an easy way to check....

-Kevin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-08-02 21:05:27 Re: patch: move dumpUserConfig call in dumpRoles function of pg_dumpall.c
Previous Message Tom Lane 2011-08-02 20:47:18 Transient plans versus the SPI API