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

Предыдущее
От: Peter Mount
Дата:
Сообщение: RE: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
Следующее
От: wieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] pltcl and LDAP