From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pl/pgsql Plan Invalidation and search_path |
Date: | 2008-03-25 02:48:02 |
Message-ID: | 200803250248.m2P2m2R08009@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Add to pl/pgsql TODO:
o Consider invalidating the cache or keeping seperate cached
copies when search_path changes
http://archives.postgresql.org/pgsql-hackers/2008-01/msg01009.php
---------------------------------------------------------------------------
Tom Lane wrote:
> Stephen Frost <sfrost(at)snowman(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-03-25 02:58:15 | Re: RFC: array_agg() per SQL:200n |
Previous Message | Bruce Momjian | 2008-03-25 02:33:45 | Re: Bug in psql/enum |