]> git.ipfire.org Git - thirdparty/postgresql.git/commit
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)
commit814a57065ec97e44de58db61a16957ddd09938e8
tree9d2ceeca7660d552fd141202c4f3a9a0cc74d2dd
parentaecefffc3f8041c883ab4fb035cf0d5519b5a7ed
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