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

Re: [HACKERS] BUG #3244: problem with PREPARE

From: "William Lawrance" <bill(dot)lawrance(at)bull(dot)com>
To: "Michael Meskes" <meskes(at)postgresql(dot)org>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-bugs(at)postgresql(dot)org>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] BUG #3244: problem with PREPARE
Date: 2007-04-24 16:29:45
Message-ID: BNEIKJMOJGCEDBNCBHEGKEPNCEAA.bill.lawrance@bull.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
In the modified version of ECPG that we used for our benchmark, we
PREPARE'd all statements.


-----Original Message-----
From: Michael Meskes [mailto:meskes(at)postgresql(dot)org]
Sent: Tuesday, April 24, 2007 12:45 AM
To: William Lawrance
Cc: Tom Lane; pgsql-bugs(at)postgresql(dot)org; pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] [BUGS] BUG #3244: problem with PREPARE


On Mon, Apr 23, 2007 at 02:02:04PM -0700, William Lawrance wrote:
> Our first attempt to use the ECPG prepare interface revealed that ECPG
> doesn't use the PQlib prepare function. The ECPG prepare replaces any
> parameters with their values and presents a new SQL statement to the

This is true and should also be documented. The reason for this
behaviour is simply that ECPG prepare feature was added before the
backend had its own prepare feature. And no one changed it so far.

> There are several difficulties to be encountered when attempting to use
> this within a program using the ECPG interface. For example, the
> connection structure for PQlib isn't readily available, and the
> transaction semantics must be synchronized with ECPG's state. This did
> work, but it was fairly clumsy.

Right, that's what makes it non trivial.

> Since we wanted to do this in a cleaner manner, and also wished to avoid
> changing the applications if possible, we used the following approach:
> 
>     Within the "execute.c" module, we added routines to manage a cache
>     of prepared statements. These routines are able to search, insert,
>     and delete entries in the cache. The key for these cache entries is
>     the text of the SQL statement as passed by ECPG from the application
>     program.
> 
>     Within the same module, we replaced the "ECPGexecute" function.
>     This is the function that is called to execute a statement after
>     some preliminary housekeeping is done. The original "ECPGexecute"
>     function constructs an ASCII string by replacing each host variable
>     with its current value and then calling "PQexec". The new
>     "ECPGexecute" function does the following:
> 
>       - build an array of the current values of the host variables.
> 
>       - search the cache for an entry indicating that this statement
>         has already been prepare'd, via  "PQprepare"
> 
>       - If no entry was found in the previous step, call "PQprepare"
>         for the statement and then insert an entry for it into the
>         cache. If this requires an entry to be re-used, execute a
>         "DEALLOCATE PREPARE.." for the previous contents.
> 
>       - At this point, the SQL statement has been prepare'd by PQlib,
>         either when the statement was executed in the past, or in
>         the previous step.
> 
>       - call "PQexecPrepared", using the array of parameters built
>         in the first step above.

Does this mean you prepare ALL statements? Or where you only talking
about statements that are prepared in the application?

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes(at)jabber(dot)org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

In response to

pgsql-hackers by date

Next:From: August ZajoncDate: 2007-04-24 16:34:09
Subject: Re: Google SoC: column-level privilege subsystem
Previous:From: Josh BerkusDate: 2007-04-24 15:31:42
Subject: Re: [HACKERS] Full page writes improvement, code update

pgsql-bugs by date

Next:From: Lee ChuaDate: 2007-04-24 18:01:46
Subject: BUG #3252: Select Order by time
Previous:From: Tom LaneDate: 2007-04-24 15:06:52
Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect

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