diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2014-04-29 13:12:26 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2014-04-29 13:12:46 -0400 |
commit | 95811032d782049642a672e3db0a5382616ab084 (patch) | |
tree | b9a5bc2f915f6c4763231c0639bd10c58f344e31 /src/backend/access/gist/gistbuild.c | |
parent | dbe31616c9be7380b8a88cdfbeaa68dbdcdebc36 (diff) | |
download | postgresql-95811032d782049642a672e3db0a5382616ab084.tar.gz postgresql-95811032d782049642a672e3db0a5382616ab084.zip |
Improve planner to drop constant-NULL inputs of AND/OR where it's legal.
In general we can't discard constant-NULL inputs, since they could change
the result of the AND/OR to be NULL. But at top level of WHERE, we do not
need to distinguish a NULL result from a FALSE result, so it's okay to
treat NULL as FALSE and then simplify AND/OR accordingly.
This is a very ancient oversight, but in 9.2 and later it can lead to
failure to optimize queries that previous releases did optimize, as a
result of more aggressive parameter substitution rules making it possible
to reduce more subexpressions to NULL constants. This is the root cause of
bug #10171 from Arnold Scheffler. We could alternatively have fixed that
by teaching orclauses.c to ignore constant-NULL OR arms, but it seems
better to get rid of them globally.
I resisted the temptation to back-patch this change into all active
branches, but it seems appropriate to back-patch as far as 9.2 so that
there will not be performance regressions of the kind shown in this bug.
Diffstat (limited to 'src/backend/access/gist/gistbuild.c')
0 files changed, 0 insertions, 0 deletions