2013/1/13 Andres Freund <and...@2ndquadrant.com>: > On 2013-01-12 15:13:51 -0500, Tom Lane wrote: >> Andres Freund <and...@2ndquadrant.com> writes: >> > On 2013-01-12 14:29:38 -0500, Tom Lane wrote: >> >> I think that the alternative most likely to succeed is to consider any >> >> change in the active value of search_path as forcing replanning of >> >> cached plans. >> >> > I guess it wouldn't really be feasible to keep the search path used to >> > plan a query in its cached form and check that it fits the one currently >> > used on every use of the cached plan? >> >> Actually that's exactly what I meant: every time we arrive at a query >> with a cached plan, check to see if the active search_path value is the >> same as what it was when we made the cached plan, and replan if not. > > Okay. I was afraid it would add noticeable overhead to stuff like > plpgsql... Maybe would lower that by having a "search_path" generation > counter that gets increased everytime it gets changed but that seems a > bit too complicated. >
we can use same mechanism, that is used for plpgsql polymorphic functions - different parameters => different instances of plpgsql function. we can store n instances per function - probably there can be memory issues when too much different search paths will be used - it is optimal probably for 10 - 100 different search paths different solution - can we specify search_path early in connection string? Then this information can be used by connection pooler - and we can do replan when different search_path is identified. Regards Pavel > Greetings, > > Andres Freund > > -- > Andres Freund http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
