Skip site navigation (1) Skip section navigation (2)


From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Karel Zak - Zakkr" <zakkr(at)zf(dot)jcu(dot)cz>
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 16:19:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> -----Original Message-----
> From: Karel Zak - Zakkr [mailto:zakkr(at)zf(dot)jcu(dot)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).



Hiroshi Inoue

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2000-02-23 16:30:10
Subject: Re: GNU make (Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error messages)
Previous:From: Tom LaneDate: 2000-02-23 16:18:43
Subject: Re: [HACKERS] Numeric with '-'

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group