diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2017-10-08 12:23:32 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2017-10-08 12:23:32 -0400 |
commit | 8ec5429e2f422f4d570d4909507db0d4ca83bbac (patch) | |
tree | 4b5ad0a3a2e0ee772ba0db8595091ead22d107d3 /src/backend/executor/nodeProjectSet.c | |
parent | b11f0d36b224a9673863b4e592f40f179dba3016 (diff) | |
download | postgresql-8ec5429e2f422f4d570d4909507db0d4ca83bbac.tar.gz postgresql-8ec5429e2f422f4d570d4909507db0d4ca83bbac.zip |
Reduce "X = X" to "X IS NOT NULL", if it's easy to do so.
If the operator is a strict btree equality operator, and X isn't volatile,
then the clause must yield true for any non-null value of X, or null if X
is null. At top level of a WHERE clause, we can ignore the distinction
between false and null results, so it's valid to simplify the clause to
"X IS NOT NULL". This is a useful improvement mainly because we'll get
a far better selectivity estimate in most cases.
Because such cases seldom arise in well-written queries, it is unappetizing
to expend a lot of planner cycles looking for them ... but it turns out
that there's a place we can shoehorn this in practically for free, because
equivclass.c already has to detect and reject candidate equivalences of the
form X = X. That doesn't catch every place that it would be valid to
simplify to X IS NOT NULL, but it catches the typical case. Working harder
doesn't seem justified.
Patch by me, reviewed by Petr Jelinek
Discussion: https://postgr.es/m/CAMjNa7cC4X9YR-vAJS-jSYCajhRDvJQnN7m2sLH1wLh-_Z2bsw@mail.gmail.com
Diffstat (limited to 'src/backend/executor/nodeProjectSet.c')
0 files changed, 0 insertions, 0 deletions