aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistget.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2014-04-29 13:12:29 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2014-04-29 13:12:29 -0400
commit150a44e83d7559000aa9578d60c8906cae097f78 (patch)
tree629ca311018b7578e0712b134c9281038d9d9c8c /src/backend/access/gist/gistget.c
parentf6590f6a8e51ec9c81fd27cc0c900282bd57487b (diff)
downloadpostgresql-150a44e83d7559000aa9578d60c8906cae097f78.tar.gz
postgresql-150a44e83d7559000aa9578d60c8906cae097f78.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/gistget.c')
0 files changed, 0 insertions, 0 deletions