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:
search_pathadd_missing_fromtransform_null_equalssql_inheritance
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.
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.
There are a boatload of other GUCs that could potentially result in
changes of planner choices:
enable_bitmapscanenable_hashaggenable_hashjoinenable_indexscanenable_mergejoinenable_nestloopenable_seqscanenable_sortenable_tidscanconstraint_exclusionfrom_collapse_limitjoin_collapse_limitgeqogeqo_effortgeqo_generationsgeqo_pool_sizegeqo_selection_biasgeqo_thresholdseq_page_costrandom_page_costcpu_tuple_costcpu_index_tuple_costcpu_operator_costeffective_cache_sizework_mem
I'm inclined not to worry about these, since changing them can't affect
the semantics of the query, at worst its performance.
One other question is exactly what "saving and restoring" search_path
should mean. We could do it textually and thus need to re-interpret
the string on each replan, or we could save the actual list of schema
OIDs. The main disadvantage of the textual way is that without some
special hack, it's possible that a replan would see the temp-table
schema as being frontmost when it had not been active at all originally;
that seems bad. OTOH if we save the OID list then it would not work
to drop a schema and rename another into its place, which is a bit
inconsistent with the fact that that does work for an individual table.
Comments?
regards, tom lane
