RE: [HACKERS] Cache query (PREPARE/EXECUTE) - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: [HACKERS] Cache query (PREPARE/EXECUTE)
Date
Msg-id 000201bf7ddb$1442dfa0$2801007e@tpf.co.jp
Whole thread Raw
In response to Re: [HACKERS] Cache query (PREPARE/EXECUTE)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses RE: [HACKERS] Cache query (PREPARE/EXECUTE)
List pgsql-hackers
> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
> 
> Karel Zak - Zakkr <zakkr@zf.jcu.cz> writes:
> >  as I said, I tring implement PREPARE / EXECUTE command for user a
> > controllable query cache (in TODO: Cache most recent query plan(s)).
> 
> Looks cool.
> 
> > The queryTree and planTree are save in hash table and in the 
> > TopMemoryContext (Is it good space for this cache?).
> 
> Probably not.  I'd suggest making a separate memory context for
> this purpose --- they're cheap, and that gives you more control.
> Look at the creation and use of CacheMemoryContext for an example.
>

Hmm,shoudn't per plan memory context be created ?

Though current SPI stuff saves prepared plans to TopMemory
Context,we couldn't remove them forever.  It seems that SPI 
should also be changed in its implementation about saving
plans.

Note that freeObject() is unavailable at all.
We would be able to free PREPAREd resources by destroying 
corrsponding memory context.

If I recognize Jan's original idea correctly,he also suggested
the same way.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp




pgsql-hackers by date:

Previous
From: Zeugswetter Andreas SB
Date:
Subject: AW: [HACKERS] TRANSACTIONS
Next
From: Zeugswetter Andreas SB
Date:
Subject: AW: [HACKERS] TRANSACTIONS