Suppress unnecessary RelabelType nodes in yet more cases.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 19 Aug 2020 18:07:49 +0000 (14:07 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 19 Aug 2020 18:07:49 +0000 (14:07 -0400)
commit69ffc2f838990fb2c802087091ce7c2ff1b735eb
tree880d7e3107a273291b59b2c38ecd3a217324736e
parentbff41b2b8938f5e3e7d536da6d7a14a1648b4dec
Suppress unnecessary RelabelType nodes in yet more cases.

Commit a477bfc1d fixed eval_const_expressions() to ensure that it
didn't generate unnecessary RelabelType nodes, but I failed to notice
that some other places in the planner had the same issue.  Really
noplace in the planner should be using plain makeRelabelType(), for
fear of generating expressions that should be equal() to semantically
equivalent trees, but aren't.

An example is that because canonicalize_ec_expression() failed
to be careful about this, we could end up with an equivalence class
containing both a plain Const, and a Const-with-RelabelType
representing exactly the same value.  So far as I can tell this led to
no visible misbehavior, but we did waste a bunch of cycles generating
and evaluating "Const = Const-with-RelabelType" to prove such entries
are redundant.

Hence, move the support function added by a477bfc1d to where it can
be more generally useful, and use it in the places where planner code
previously used makeRelabelType.

Back-patch to v12, like the previous patch.  While I have no concrete
evidence of any real misbehavior here, it's certainly possible that
I overlooked a case where equivalent expressions that aren't equal()
could cause a user-visible problem.  In any case carrying extra
RelabelType nodes through planning to execution isn't very desirable.

Discussion: https://postgr.es/m/1311836.1597781384@sss.pgh.pa.us
src/backend/nodes/nodeFuncs.c
src/backend/optimizer/path/equivclass.c
src/backend/optimizer/prep/prepunion.c
src/backend/optimizer/util/clauses.c
src/include/nodes/nodeFuncs.h