aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2009-09-12 22:12:09 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2009-09-12 22:12:09 +0000
commit9bb342811bf6a93a574a648c5848feedbaaef8f2 (patch)
treeecc60f3017cc58695c4c96ebf6d11669e3de6900 /src/backend/executor
parent5f1b32ddf826550d65dd6e84b965b6a98589ad19 (diff)
downloadpostgresql-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.c29
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;
+}