vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| Add to pl/pgsql TODO: o Consider invalidating the cache or keeping seperate cached copies when search_path changes http://archives.postgresql.org/pgsql...1/msg01009.php --------------------------------------------------------------------------- Tom Lane wrote: > Stephen Frost <sfrost@snowman.net> writes: > > In doing some test on 8.3RC2, I was dismayed to discover that the > > pl/pgsql plan invalidation logic added doesn't consider changing the > > search_path to invalidate a plan. > > We never considered it so before, either. The plancache code goes out > of its way to maintain the same path that was used initially, and > I think that's what it should do: a cache module should avoid letting > the semantics of what it's cached change without the caller's knowledge. > If we were to change this, we'd probably have to think in terms of > making the active search_path be part of the lookup key for cached plans. > > > Would it be possible to have this case handled? > > It's far too late to reconsider this point for 8.3. If you want to > bring it up for 8.4, we could think about what the behavioral and > performance implications would really be. In the meantime, the answer > is the same as it's always been: if that's what you want, use EXECUTE. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |
| |||
| On Mon, Mar 24, 2008 at 9:48 PM, Bruce Momjian <bruce@momjian.us> wrote: > > Add to pl/pgsql TODO: > > o Consider invalidating the cache or keeping seperate cached > copies when search_path changes > > http://archives.postgresql.org/pgsql...1/msg01009.php IMO, Tom's idea, namely to keep separate cache plans for various search_path settings, is a much stronger proposal and should probably get the 'todo'. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |
| ||||
| Merlin Moncure wrote: > On Mon, Mar 24, 2008 at 9:48 PM, Bruce Momjian <bruce@momjian.us> wrote: > > > > Add to pl/pgsql TODO: > > > > o Consider invalidating the cache or keeping seperate cached > > copies when search_path changes > > > > http://archives.postgresql.org/pgsql...1/msg01009.php > > IMO, Tom's idea, namely to keep separate cache plans for various > search_path settings, is a much stronger proposal and should probably > get the 'todo'. Done: o Consider keeping seperate cached copies when search_path changes -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |