diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2009-09-12 22:12:09 +0000 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2009-09-12 22:12:09 +0000 |
commit | 9bb342811bf6a93a574a648c5848feedbaaef8f2 (patch) | |
tree | ecc60f3017cc58695c4c96ebf6d11669e3de6900 /src/backend/executor | |
parent | 5f1b32ddf826550d65dd6e84b965b6a98589ad19 (diff) | |
download | postgresql-9bb342811bf6a93a574a648c5848feedbaaef8f2.tar.gz postgresql-9bb342811bf6a93a574a648c5848feedbaaef8f2.zip |
Rewrite the planner's handling of materialized plan types so that there is
an explicit model of rescan costs being different from first-time costs.
The costing of Material nodes in particular now has some visible relationship
to the actual runtime behavior, where before it was essentially fantasy.
This also fixes up a couple of places where different materialized plan types
were treated differently for no very good reason (probably just oversights).
A couple of the regression tests are affected, because the planner now chooses
to put the other relation on the inside of a nestloop-with-materialize.
So far as I can see both changes are sane, and the planner is now more
consistently following the expectation that it should prefer to materialize
the smaller of two relations.
Per a recent discussion with Robert Haas.
Diffstat (limited to 'src/backend/executor')
-rw-r--r-- | src/backend/executor/execAmi.c | 29 |
1 files changed, 28 insertions, 1 deletions
diff --git a/src/backend/executor/execAmi.c b/src/backend/executor/execAmi.c index cd23d8d8b64..51923c436ad 100644 --- a/src/backend/executor/execAmi.c +++ b/src/backend/executor/execAmi.c @@ -6,7 +6,7 @@ * Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * - * $PostgreSQL: pgsql/src/backend/executor/execAmi.c,v 1.103 2009/01/01 17:23:41 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/executor/execAmi.c,v 1.104 2009/09/12 22:12:03 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -496,3 +496,30 @@ IndexSupportsBackwardScan(Oid indexid) return result; } + +/* + * ExecMaterializesOutput - does a plan type materialize its output? + * + * Returns true if the plan node type is one that automatically materializes + * its output (typically by keeping it in a tuplestore). For such plans, + * a rescan without any parameter change will have zero startup cost and + * very low per-tuple cost. + */ +bool +ExecMaterializesOutput(NodeTag plantype) +{ + switch (plantype) + { + case T_Material: + case T_FunctionScan: + case T_CteScan: + case T_WorkTableScan: + case T_Sort: + return true; + + default: + break; + } + + return false; +} |