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

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема RE: [HACKERS] Cache query (PREPARE/EXECUTE)
Дата
Msg-id 000201bf7ddb$1442dfa0$2801007e@tpf.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] Cache query (PREPARE/EXECUTE)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы RE: [HACKERS] Cache query (PREPARE/EXECUTE)  (Karel Zak - Zakkr <zakkr@zf.jcu.cz>)
Список 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 по дате отправления:

Предыдущее
От: Zeugswetter Andreas SB
Дата:
Сообщение: AW: [HACKERS] TRANSACTIONS
Следующее
От: Zeugswetter Andreas SB
Дата:
Сообщение: AW: [HACKERS] TRANSACTIONS