Drop no-op CoerceToDomain nodes from expressions at planning time

Enterprise / PostgreSQL - Tom Lane [sss.pgh.pa.us] - 13 December 2018 18:24 EST

If a domain has no constraints, then CoerceToDomain doesn't really do anything and can be simplified to a RelabelType. This not only eliminates cycles at execution, but allows the planner to optimize better (for instance, match the coerced expression to an index on the underlying column). However, we do have to support invalidating the plan later if a constraint gets added to the domain. That's comparable to the case of a change to a SQL function that had been inlined into a plan, so all the necessary logic already exists for plans depending on functions. We need only duplicate or share that logic for domains.

ALTER DOMAIN ADD/DROP CONSTRAINT need to be taught to send out sinval messages for the domain's pg_type entry, since those operations don't update that row. (ALTER DOMAIN SET/DROP NOT NULL do update that row, so no code change is needed for them.)

Testing this revealed what's really a pre-existing bug in plpgsql: it caches the SQL-expression-tree expansion of type coercions and had no provision for invalidating entries in that cache. Up to now that was only a problem if such an expression had inlined a SQL function that got changed, which is unlikely though not impossible. But failing to track changes of domain constraints breaks an existing regression test case and would likely cause practical problems too.

We could fix that locally in plpgsql, but what seems like a better idea is to build some generic infrastructure in plancache.c to store standalone expressions and track invalidation events for them. (It's tempting to wonder whether plpgsql's "simple expression" stuff could use this code with lower overhead than its current use of the heavyweight plancache APIs. But I've left that idea for later.)

Other stuff fixed in passing:

- Allow estimate_expression_value() to drop CoerceToDomain unconditionally, effectively assuming that the coercion will succeed. This will improve planner selectivity estimates for cases involving estimatable expressions that are coerced to domains. We could have done this independently of everything else here, but there wasn't previously any need for eval_const_expressions_mutator to know about CoerceToDomain at all.

- Use a dlist for plancache.c's list of cached plans, rather than a manually threaded singly-linked list. That eliminates a potential performance problem in DropCachedPlan.

- Fix a couple of inconsistencies in typecmds.c about whether operations on domains drop RowExclusiveLock on pg_type. Our common practice is that DDL operations do drop catalog locks, so standardize on that choice.

Discussion: https://postgr.es/m/19958.1544122124@sss.pgh.pa.us

04fe805a17 Drop no-op CoerceToDomain nodes from expressions at planning time.
src/backend/commands/typecmds.c | 22 +++-
src/backend/optimizer/plan/planner.c | 59 ++++++++-
src/backend/optimizer/plan/setrefs.c | 64 ++++++++--
src/backend/optimizer/util/clauses.c | 66 +++++++++-
src/backend/utils/cache/plancache.c | 228 ++++++++++++++++++++++++++++-------
src/backend/utils/cache/typcache.c | 11 +-
src/include/optimizer/planmain.h | 2 +
src/include/optimizer/planner.h | 3 +
src/include/utils/plancache.h | 51 ++++++--
src/pl/plpgsql/src/pl_exec.c | 51 ++++----
src/test/regress/expected/domain.out | 25 ++++
src/test/regress/sql/domain.sql | 20 +++
12 files changed, 510 insertions(+), 92 deletions(-)

Upstream: git.postgresql.org


  • Share