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