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 <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support