[HACKERS] SPI and qCache and bug?
От | Karel Zak - Zakkr |
---|---|
Тема | [HACKERS] SPI and qCache and bug? |
Дата | |
Msg-id | Pine.LNX.3.96.1000308173104.14462F-100000@ara.zf.jcu.cz обсуждение исходный текст |
Ответ на | SPI and qCache and bug? (Karel Zak - Zakkr <zakkr@zf.jcu.cz>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: