diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2006-07-01 18:38:33 +0000 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2006-07-01 18:38:33 +0000 |
commit | cffd89ca736e485309cd51ae056f837bd7e683ad (patch) | |
tree | 7ebf13ae5d921d074382d80be66a8d97e7a822e1 /src/backend/access/gist/gistxlog.c | |
parent | 68628fc38ea7a3c72f6a813b0193d836731d9c10 (diff) | |
download | postgresql-cffd89ca736e485309cd51ae056f837bd7e683ad.tar.gz postgresql-cffd89ca736e485309cd51ae056f837bd7e683ad.zip |
Revise the planner's handling of "pseudoconstant" WHERE clauses, that is
clauses containing no variables and no volatile functions. Such a clause
can be used as a one-time qual in a gating Result plan node, to suppress
plan execution entirely when it is false. Even when the clause is true,
putting it in a gating node wins by avoiding repeated evaluation of the
clause. In previous PG releases, query_planner() would do this for
pseudoconstant clauses appearing at the top level of the jointree, but
there was no ability to generate a gating Result deeper in the plan tree.
To fix it, get rid of the special case in query_planner(), and instead
process pseudoconstant clauses through the normal RestrictInfo qual
distribution mechanism. When a pseudoconstant clause is found attached to
a path node in create_plan(), pull it out and generate a gating Result at
that point. This requires special-casing pseudoconstants in selectivity
estimation and cost_qual_eval, but on the whole it's pretty clean.
It probably even makes the planner a bit faster than before for the normal
case of no pseudoconstants, since removing pull_constant_clauses saves one
useless traversal of the qual tree. Per gripe from Phil Frost.
Diffstat (limited to 'src/backend/access/gist/gistxlog.c')
0 files changed, 0 insertions, 0 deletions