Thread: Query cache import?
I never saw much traffic regarding Karel's work on making stored proceedures: http://people.freebsd.org/~alfred/karel-pgsql.txt What happened with this? It looked pretty interesting. :( -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk."
Thanks for the info.
On Tue, 31 Oct 2000, Alfred Perlstein wrote: > I never saw much traffic regarding Karel's work on making stored > proceedures: > > http://people.freebsd.org/~alfred/karel-pgsql.txt > > What happened with this? It looked pretty interesting. :( It's probably a little about me :-) ... well, My query cache is in usable state and it's efficient for all things those motivate me to work on this. some basic features: - share parsed plans between backends in shared memory- store plans to private backend hash table- use parameters for storedqueries- better design for SPI - memory usage for saved plans - save plans "by key" The current query cache code depend on 7.1 memory management. After official 7.1 release I prepare patch with query cache+SPI (if not hit me over head, please ..) All what will doing next time not depend on me, *it's on code developers*. For example Jan has interesting idea about caching all plans which processing backend. But it's far future and IMHO we must go by small steps to Oracle's funeral :-) If I need the query cache in the my work (typical for some web+pgsql) or will some public interest I will continue on this, if not I freeze it. (Exists more interesting work like http://mape.jcu.cz ... sorry of advertising :-) Karel
> My query cache is in usable state and it's efficient for all things > those motivate me to work on this. Well, you know, us application developers are lazy egoists, we want all of that without efforts on our side :) In fact, customers do that. They don't want to pay for both implementing query cache and re-writing applications.I suggest by your description that it shouldn'tbe a brain surgery to apply your caching to a stable server, so when I'll have a chance to put my hands on a busy discussion forum next time, it'd be nice to give it a whirl. -- contaminated fish and microchips huge supertankers on Arabian tripsoily propaganda from the leaders' lips all about the futurethere'speople over here, people over there everybody's looking for a little more aircrossing all the borders just totake their share planning for the future Rainbow, Difficult to Cure
* Karel Zak <zakkr@zf.jcu.cz> [001031 16:18] wrote: > > On Tue, 31 Oct 2000, Alfred Perlstein wrote: > > > I never saw much traffic regarding Karel's work on making stored > > proceedures: > > > > http://people.freebsd.org/~alfred/karel-pgsql.txt > > > > What happened with this? It looked pretty interesting. :( > > It's probably a little about me :-) ... well, > > My query cache is in usable state and it's efficient for all > things those motivate me to work on this. > > some basic features: > > - share parsed plans between backends in shared memory > - store plans to private backend hash table > - use parameters for stored queries > - better design for SPI > - memory usage for saved plans > - save plans "by key" > > > The current query cache code depend on 7.1 memory management. After > official 7.1 release I prepare patch with query cache+SPI (if not > hit me over head, please ..) > > All what will doing next time not depend on me, *it's on code developers*. > > For example Jan has interesting idea about caching all plans which > processing backend. But it's far future and IMHO we must go by small > steps to Oracle's funeral :-) Well I'm just hoping that perl's $dbh->prepare() actually does a temporary stored proceedure so that I can shave cycles off of my thousands upon thousands of repeated queries. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk."
On Tue, 31 Oct 2000, Alfred Perlstein wrote: > * Karel Zak <zakkr@zf.jcu.cz> [001031 16:18] wrote: > > > > On Tue, 31 Oct 2000, Alfred Perlstein wrote: > > > > All what will doing next time not depend on me, *it's on code developers*. ^^^^^^^^ right is "core" > Well I'm just hoping that perl's $dbh->prepare() actually does a > temporary stored proceedure so that I can shave cycles off of > my thousands upon thousands of repeated queries. :) IMHO implement good cache for planns is not easy, if is wanted use cached planns in more backend and store it in shared memory. I wrote for this new memory context type. My idea is not save/share parsed planns only for PREPARE/EXECUTE statemment but for SPI (triggers - FK for example) too. It expect support inside backend and not is possible write it in some application layout (at client). But it's very good "investment", because query pasring in the PG is very expensive (all in queries is dynamic). In my tests is execute for stored planns very faster (90%) for queries that spending more time in the parser/planner/rewriter. Karel