Thread: SPI and qCache and bug?

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 neverunallocated TopMemoryContext.
New:
     SPI_saveplan_by_key()   - save plan to qcache under specifited hash key. This is needful if user define key
oneselfor 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 keyonly, (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 allmemory associate with plan. It is end of the
TopMemoryContextfeeding:-)
 
Comments?
 A question: I look at the current PG's SPI and (IMHO) is here a littleperformance bug. Very often is used
SPI_prepare()and SPI_saveplan()together and without any relevant code between these routines. But see:SPI_prepare() -
call2x 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)
datato        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 toTopMemoryContext (or to qCache), we not need data in
procedurecontext (as it copy SPI_prepare), because SPI_execp() copy it to wanted contextitself. 
 
The SPI performance will interesting if RI will in real life...       
                    Karel

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