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_path
add_missing_from
transform_null_equals
sql_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_bitmapscan
enable_hashagg
enable_hashjoin
enable_indexscan
enable_mergejoin
enable_nestloop
enable_seqscan
enable_sort
enable_tidscan
constraint_exclusion
from_collapse_limit
join_collapse_limit
geqo
geqo_effort
geqo_generations
geqo_pool_size
geqo_selection_bias
geqo_threshold
seq_page_cost
random_page_cost
cpu_tuple_cost
cpu_index_tuple_cost
cpu_operator_cost
effective_cache_size
work_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
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
