Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group