RE: [HACKERS] Cache query (PREPARE/EXECUTE)
От | Hiroshi Inoue |
---|---|
Тема | RE: [HACKERS] Cache query (PREPARE/EXECUTE) |
Дата | |
Msg-id | NDBBIJLOILGIKBGDINDFIEPECCAA.Inoue@tpf.co.jp обсуждение исходный текст |
Ответ на | RE: [HACKERS] Cache query (PREPARE/EXECUTE) (Karel Zak - Zakkr <zakkr@zf.jcu.cz>) |
Ответы |
Re: [HACKERS] Cache query (PREPARE/EXECUTE)
|
Список | pgsql-hackers |
> -----Original Message----- > From: Karel Zak - Zakkr [mailto:zakkr@zf.jcu.cz] > > > 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 I think so. The problem is that Node struct couldn't be freed safely due to the lack of reference count in its definition. As far as I see plans could be destroyed only when the memory context in which they are placed are destroyed. > 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)). > You can DROP a PLAN by removing its hash entry but of cource there remains memory leak. > If I call SPI_saveplan(), is the plan forever save in > TopMemoryContext? (hmm, the SPI is memory feeder). > Probably. Regards. Hiroshi Inoue Inoue@tpf.co.jp
В списке pgsql-hackers по дате отправления: