Re: Cache for query plans
От | Jan Wieck |
---|---|
Тема | Re: Cache for query plans |
Дата | |
Msg-id | 200105301911.f4UJBmg07829@jupiter.us.greatbridge.com обсуждение исходный текст |
Ответ на | Cache for query plans ("Roberto Abalde" <roberto.abalde@galego21.org>) |
Список | pgsql-hackers |
Roberto Abalde wrote: > Hi, > > I need to implement a cache for query plans as part of my BSc thesis. Does > anybody know what happened to Karel Zak's patch? Dunno. > I'm also looking for some comments & tips about how to implement a cache for > query plans and how to deal with the implementation of shared memory in > PSQL. Query trees and -plans are only handled on the backend side. And don't forget that dealing with such thing on the client side, which allmost runs under clients memory control, opens a can of worms with respect to security and other issues. Plus it's not a psql only thing. If you want applications to benefit from it, it has to be implementedon the libpq level. That said, general purpose query cacheing using shared memory must at least run the parser on each query string. It could then build some hash key based on the querytree node structure and hold query trees and -plans in shared memory. If it finds a query with the same key in it's cache, it'll take a closer look if the cached and actualquery only differ in const nodes and instead of planning/optimizing again it'll just use the cached one. A queryshouldn't make it into the cache just at first occurence, but it's hash key does and is subsequently countedup. Combined with some ageing and the rest of required herbs it'll serve a good meal for some types of applications. Thus, it has to be a per database configurable feature. Explicit PREPARE and EXECUTE statements (or whatever keywords actually used) are IMHO better candidates for a per session (backend) non-shared implementation, because how could another client be sure that a given query identifieractually does or doesn't exist and what querystring is/should be associated with it? > Greetings, > Roberto > > PS: Sorry for my english :( What's wrong with it? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com # _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
В списке pgsql-hackers по дате отправления: