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 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