From: | Karel Zak - Zakkr <zakkr(at)zf(dot)jcu(dot)cz> |
---|---|
To: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | RE: [HACKERS] Cache query (PREPARE/EXECUTE) |
Date: | 2000-02-23 10:26:27 |
Message-ID: | Pine.LNX.3.96.1000223105510.15474A-100000@ara.zf.jcu.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Alessio Bragadini | 2000-02-23 10:43:49 | Re: [HACKERS] Big join breaks psql |
Previous Message | Jan Wieck | 2000-02-23 10:22:52 | Re: [HACKERS] pltcl and LDAP |