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
