Tom Lane wrote:
Now that there's a mechanism in the backend that will automatically replan
queries whenever anything changes about the referenced tables, we have to
worry about whether an automatic replan might cause surprising changes in
the behavior of a query. I looked through the available GUC settings to
see what would affect a replan, and came up with just four that would
potentially affect the semantics of the query:
As I've already mentioned, I think we must address search_path by saving
the path at time of first plan and using that same path during any replan.
Yes. I think this is the only secure way to do it.
However, I'm not excited about adding mechanism to similarly save and
restore the others. They're all for legacy-app compatibility and so
seem unlikely to be changed on-the-fly within a session. Also,
add_missing_from and transform_null_equals aren't going to affect sanely
written queries in the first place. sql_inheritance is a little bit
bigger deal, but I wonder whether we shouldn't just remove that variable
altogether --- it's been default ON since 7.1 and I've not heard anyone
complain about that in a long time.
Let's do a quick survey on a couple mailing lists.
There are a boatload of other GUCs that could potentially result in
changes of planner choices:
I think the only thing we need do about the GUCs is provide the user
with a command which flushes all plans for the session. Hmmmm, that's
not really necessary I suppose; one can easily reconnect.
For that matter, can anyone think why we'd need a command for the
superuser to flush all plans in the server? It seems like something we
ought to have, but I don't have a good case why ...
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings