RE: [HACKERS] Cache query (PREPARE/EXECUTE)
От | Karel Zak - Zakkr |
---|---|
Тема | RE: [HACKERS] Cache query (PREPARE/EXECUTE) |
Дата | |
Msg-id | Pine.LNX.3.96.1000223105510.15474A-100000@ara.zf.jcu.cz обсуждение исходный текст |
Ответ на | RE: [HACKERS] Cache query (PREPARE/EXECUTE) ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Ответы |
RE: [HACKERS] Cache query (PREPARE/EXECUTE)
|
Список | pgsql-hackers |
> 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. Yes, I know about SPI plan saving... from here is my inspiration with TopMemoryContext. But we have in current PG code very often any cached queryPlan/Tree (PREPARE, SPI and Jan's RI saves plans to TopM. too), I agree with Tom that is not bad idea saving all plans to _one_ specific MemoryContext. My idea is make any basic routines for query cache (hash table, ExecuteCachedQuery() ...etc) and use these routines for more operation (SPI, FKeys, PREPARE..). Comments? > Note that freeObject() is unavailable at all. > We would be able to free PREPAREd resources by destroying > corrsponding memory context. If I good understand, we can't destroy any plan? We must destroy _full_ memory context? If yes (please no), we can't make a DROP PLAN command or we must create for each plan specific memory context (and drop this specific Context (Jan's original idea)). If I call SPI_saveplan(), is the plan forever save in TopMemoryContext? (hmm, the SPI is memory feeder). Karel
В списке pgsql-hackers по дате отправления: