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)
|
Список | 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 по дате отправления: