From: | tgl(at)svr1(dot)postgresql(dot)org (Tom Lane) |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Teach the planner to remove SubqueryScan nodes from the plan if |
Date: | 2005-05-22 22:30:20 |
Message-ID: | 20050522223020.8DBDC52874@svr1.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Log Message:
-----------
Teach the planner to remove SubqueryScan nodes from the plan if they
aren't doing anything useful (ie, neither selection nor projection).
Also, extend to SubqueryScan the hacks already in place to avoid
unnecessary ExecProject calls when the result would just be the same
tuple the subquery already delivered. This saves some overhead in
UNION and other set operations, as well as avoiding overhead for
unflatten-able subqueries. Per example from Sokolov Yura.
Modified Files:
--------------
pgsql/src/backend/executor:
execMain.c (r1.248 -> r1.249)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execMain.c.diff?r1=1.248&r2=1.249)
execScan.c (r1.35 -> r1.36)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execScan.c.diff?r1=1.35&r2=1.36)
nodeAppend.c (r1.63 -> r1.64)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeAppend.c.diff?r1=1.63&r2=1.64)
nodeFunctionscan.c (r1.33 -> r1.34)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeFunctionscan.c.diff?r1=1.33&r2=1.34)
nodeSubqueryscan.c (r1.25 -> r1.26)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeSubqueryscan.c.diff?r1=1.25&r2=1.26)
pgsql/src/backend/optimizer/plan:
createplan.c (r1.188 -> r1.189)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/createplan.c.diff?r1=1.188&r2=1.189)
planner.c (r1.185 -> r1.186)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/planner.c.diff?r1=1.185&r2=1.186)
setrefs.c (r1.109 -> r1.110)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/setrefs.c.diff?r1=1.109&r2=1.110)
pgsql/src/backend/optimizer/prep:
prepunion.c (r1.120 -> r1.121)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/prep/prepunion.c.diff?r1=1.120&r2=1.121)
pgsql/src/backend/optimizer/util:
clauses.c (r1.196 -> r1.197)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/util/clauses.c.diff?r1=1.196&r2=1.197)
plancat.c (r1.106 -> r1.107)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/util/plancat.c.diff?r1=1.106&r2=1.107)
pgsql/src/include/optimizer:
clauses.h (r1.78 -> r1.79)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/optimizer/clauses.h.diff?r1=1.78&r2=1.79)
planmain.h (r1.84 -> r1.85)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/optimizer/planmain.h.diff?r1=1.84&r2=1.85)
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2005-05-23 01:29:54 | pgsql: Consistently do not include a terminating period in |
Previous Message | Bruce Momjian | 2005-05-21 21:31:27 | pgsql: INT4 is probably enough: < * Allow INET + INT4/INT8 to increment |