Excerpts from Tom Lane's message of jue nov 11 19:21:34 -0300 2010: > I've been thinking about supporting automatic replan of cached plans > using specific parameter values, as has been discussed several times, > at greatest length in this thread: > http://archives.postgresql.org/pgsql-hackers/2010-02/msg00607.php > There doesn't seem to be full consensus about what the control method > ought to be, but right at the moment I'm thinking about mechanism not > policy. I think that what we need to do is restructure the API of > plancache.c to make it more amenable to returning "throwaway" plans. > It can already do that to some extent using the fully_planned = false > code path, but that's not the design center and it was shoehorned in > in perhaps a less than clean fashion. I want to rearrange it so there's > an explicit notion of three levels of cacheable object:
I was wondering if this could help with the separation of labour of functions in postgres.c that we were talking about a couple of weeks ago. The main impedance mismatch, so to speak, is that those functions aren't at all related to caching of any sort; but then, since you're looking for a new name for the source file, I return to my earlier suggestion of a generic "queries.c" or some such, which could handle all these issues. (Of course, querycache.c doesn't make any sense.) -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
