database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-27 23:21:58 +03:00
Code Activity

Rewrite the planner's handling of materialized plan types so that there is

Browse Source 
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.
This commit is contained in:
Tom Lane
2009-09-12 22:12:09 +00:00
parent 5f1b32ddf8
commit 9bb342811b
12 changed files with 1029 additions and 916 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
src/backend/optimizer/path/joinpath.c
View File

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/optimizer/path/joinpath.c,v 1.122 2009/06/11 14:48:59 momjian Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/path/joinpath.c,v 1.123 2009/09/12 22:12:04 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -16,6 +16,7 @@
#include <math.h>
#include "executor/executor.h"
#include "optimizer/cost.h"
#include "optimizer/pathnode.h"
#include "optimizer/paths.h"
@ -405,18 +406,10 @@ match_unsorted_outer(PlannerInfo *root,
else if (nestjoinOK)
{
/*
* If the cheapest inner path is a join or seqscan, we should consider
* materializing it. (This is a heuristic: we could consider it
* always, but for inner indexscans it's probably a waste of time.)
* Also skip it if the inner path materializes its output anyway.
* Consider materializing the cheapest inner path, unless it is one
* that materializes its output anyway.
*/
if (!(inner_cheapest_total->pathtype == T_IndexScan ||
inner_cheapest_total->pathtype == T_BitmapHeapScan ||
inner_cheapest_total->pathtype == T_TidScan ||
inner_cheapest_total->pathtype == T_Material ||
inner_cheapest_total->pathtype == T_FunctionScan ||
inner_cheapest_total->pathtype == T_CteScan ||
inner_cheapest_total->pathtype == T_WorkTableScan))
if (!ExecMaterializesOutput(inner_cheapest_total->pathtype))
matpath = (Path *)
create_material_path(innerrel, inner_cheapest_total);