

 Hi,

 query cache hacking continue ...

 I just implement my (context-per-plan) query cache (qCache) to SPI. 

 Changed:

      SPI_saveplan()          - save plan to qcache instead to never
	unallocated TopMemoryContext.

 New:

      SPI_saveplan_by_key()   - save plan to qcache under specifited hash 
	key. This is needful if user define key oneself or if key must be 
	binary (non-string) - example Jan use any struct as hash key in RI's 
	triggers.) 

      SPI_execp_by_key()      - same as SPI_execp(), but as arg is hash key
	only, (again, it is needful for (example) RI).
	- you not need pointer to plan, you can use key only

      SPI_freeplan()          - remove plan from qcache and destroy all
	memory associate with plan. It is end of the TopMemoryContext
	feeding :-)

 Comments?

  A question: I look at the current PG's SPI and (IMHO) is here a little
 performance bug. Very often is used SPI_prepare() and SPI_saveplan()
 together and without any relevant code between these routines. But see:
	
	SPI_prepare() - call 2x copyObject() and copy data to procedure 
			context

	- well, if you need pquery plans in this context it is OK, but
  
	SPI_saveplan() - call 2x copyObject() and copy (same) data to
			TopMemoryContext (or in future to qCache)

	SPI_execp() - call 2x copyObject() and copy data back to current 
			context

	- hmm, it copy twice all data, but without any efect.

 IMHO is solution any SPI_prepare_and_save() and copy data only to
 TopMemoryContext (or to qCache), we not need data in procedure context 
 (as it copy SPI_prepare), because SPI_execp() copy it to wanted context
 itself. 

 The SPI performance will interesting if RI will in real life...
  	  

						Karel


 





Thu, 2 Mar 2000 17:32:51 +0100 (CET)
Karel Zak - Zakkr <zakkr@zf.jcu.cz>
SPI and qCache and bug?


 Still quiet for this question?  Hmm.. (not interesting?)
 

On Thu, 2 Mar 2000, Karel Zak - Zakkr wrote:
> 
> 
>  Hi,
> 
>  query cache hacking continue ...
> 
>  I just implement my (context-per-plan) query cache (qCache) to SPI. 
> 
>  Changed:
> 
>       SPI_saveplan()          - save plan to qcache instead to never
> 	unallocated TopMemoryContext.
> 
>  New:
> 
>       SPI_saveplan_by_key()   - save plan to qcache under specifited hash 
> 	key. This is needful if user define key oneself or if key must be 
> 	binary (non-string) - example Jan use any struct as hash key in RI's 
> 	triggers.) 
> 
>       SPI_execp_by_key()      - same as SPI_execp(), but as arg is hash key
> 	only, (again, it is needful for (example) RI).
> 	- you not need pointer to plan, you can use key only
> 
>       SPI_freeplan()          - remove plan from qcache and destroy all
> 	memory associate with plan. It is end of the TopMemoryContext
> 	feeding :-)
> 
>  Comments?
> 
>   A question: I look at the current PG's SPI and (IMHO) is here a little
>  performance bug. Very often is used SPI_prepare() and SPI_saveplan()
>  together and without any relevant code between these routines. But see:
> 	
> 	SPI_prepare() - call 2x copyObject() and copy data to procedure 
> 			context
> 
> 	- well, if you need pquery plans in this context it is OK, but
>   
> 	SPI_saveplan() - call 2x copyObject() and copy (same) data to
> 			TopMemoryContext (or in future to qCache)
> 
> 	SPI_execp() - call 2x copyObject() and copy data back to current 
> 			context
> 
> 	- hmm, it copy twice all data, but without any efect.
> 
>  IMHO is solution any SPI_prepare_and_save() and copy data only to
>  TopMemoryContext (or to qCache), we not need data in procedure context 
>  (as it copy SPI_prepare), because SPI_execp() copy it to wanted context
>  itself. 
> 
>  The SPI performance will interesting if RI will in real life...
>   	  
> 
> 						Karel


Wed, 8 Mar 2000 17:33:39 +0100 (CET)
Karel Zak - Zakkr <zakkr@zf.jcu.cz>
[HACKERS] SPI and qCache and bug?