[HACKERS] Cache query implemented - Mailing list pgsql-hackers

From Karel Zak - Zakkr
Subject [HACKERS] Cache query implemented
Date
Msg-id Pine.LNX.3.96.1000224175739.17426A-100000@ara.zf.jcu.cz
Whole thread Raw
In response to Re: [HACKERS] Cache query (PREPARE/EXECUTE)  (wieck@debis.com (Jan Wieck))
Responses Re: [HACKERS] Cache query implemented  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Wed, 23 Feb 2000, Jan Wieck wrote:
> 
>     I  don't  see  much complexity difference between one context
>     per plan vs. one context for  all.  At  least  if  we  do  it
>     transparently inside of SPI_saveplan() and SPI_freeplan().
> 
Well, I explore PG's memory context routines and is probably more
simple destroy mem context (than use feeeObject()) and create new context
for plan is simple too. (Jan, Hiroshi and PG's source convince me :-)
Today afternoon I rewrite query cache and now is implemented as 
'context-per-plan'. It allows me write a 'DROP PLAN' command. We can use 
this cache in SPI too, and create new command SPI_freeplan() (and stop 
TopMemoryContext feeding).
Now, PREPARE/EXECUTE are ready to usage. See:

test=# prepare my_plan as select * from tab where id = $1 using int;
PREPARE
test=# execute my_plan using 2;id | data
----+------ 2 | aaaa
(1 row)

test=# drop plan my_plan;
DROP
test=# execute my_plan using 2;
ERROR:  Plan with name 'my_plan' not existI still not sure with PREPARE/EXECUTE keywords, I vote for:
CREATE PLAN name AS query [ USING type, ... ]EXECUTE PLAN name [ USING values, ... ]DROP PLAN name
Comments? (Please. I really not SQL's standard guru...)
                    Karel



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0
Next
From: "Keith G. Murphy"
Date:
Subject: Re: [GENERAL] Re: [HACKERS] TRANSACTIONS