RE: [HACKERS] Cache query (PREPARE/EXECUTE)

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Karel Zak - Zakkr" <zakkr(at)zf(dot)jcu(dot)cz>
Cc: "pgsql-hackers" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: RE: [HACKERS] Cache query (PREPARE/EXECUTE)
Date: 2000-02-23 08:50:48
Message-ID: 000201bf7ddb$1442dfa0$2801007e@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: owner-pgsql-hackers(at)postgreSQL(dot)org
> [mailto:owner-pgsql-hackers(at)postgreSQL(dot)org]On Behalf Of Tom Lane
>
> Karel Zak - Zakkr <zakkr(at)zf(dot)jcu(dot)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(at)tpf(dot)co(dot)jp

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SB 2000-02-23 08:52:59 AW: [HACKERS] TRANSACTIONS
Previous Message Zeugswetter Andreas SB 2000-02-23 08:26:32 AW: [HACKERS] TRANSACTIONS