Re: Transient plans versus the SPI API - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Transient plans versus the SPI API
Date
Msg-id 4E381FC9020000250003F9BF@gw.wicourts.gov
Whole thread Raw
In response to Transient plans versus the SPI API  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Transient plans versus the SPI API
Next
From: Tom Lane
Date:
Subject: Re: patch: move dumpUserConfig call in dumpRoles function of pg_dumpall.c