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

Re: PREPARE/EXECUTE across backends?

From: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Jingren Zhou <jrzhoupro(at)hotmail(dot)com>,PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PREPARE/EXECUTE across backends?
Date: 2003-10-02 08:19:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Oct 01, 2003 at 09:01:23PM -0400, Neil Conway wrote:
> On Wed, 2003-10-01 at 20:25, Jingren Zhou wrote:
> > From the document, it seems that PREPARE/EXECUTE works only in the same 
> > session. I am wondering whether postgres can prepare a query (save the plan) 
> > for difference backends.
> The decision to store prepared statements per-backend, rather than in
> shared memory, was made deliberately. In fact, an early version of the
> PREPARE/EXECUTE patch (written by Karel Zak) stored prepared statements
> in shared memory. But I decided to remove this, because:

> That's all the reasons I can think of off the top of my head for doing
> things the way we do. However, I'm open to being convinced: if you think
> we should store prepared statements in shm, feel free to make a case for
> it.

 I think  the current non-shared PREPARE/EXECUTE  is right solution. The
 shared version  require define  new type  of memory  managment routines
 which is full compatible with the standard and abstract PostgreSQL mmgr
 tier.  I worked  on this because it was interesting  experiment and now
 we know that write something like this is possible :-)

 I  think final  and right  solution are  persisten pre-forked  backends
 which know  to keep cached PREPARE/EXECUTE  stuff (and a lot  of others
 things) in  own memory. It's nice  and simple solution than  use shared

 Karel Zak  <zakkr(at)zf(dot)jcu(dot)cz>

In response to

pgsql-hackers by date

Next:From: Christopher Kings-LynneDate: 2003-10-02 08:29:14
Subject: Weird locking situation
Previous:From: Greg StarkDate: 2003-10-02 07:48:24

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