pgsql: Temporarily (I hope) disable flattening of IN/EXISTS sublinks
Log Message:
-----------
Temporarily (I hope) disable flattening of IN/EXISTS sublinks that are within
the ON clause of an outer join. Doing so is semantically correct but results
in de-optimizing queries that were structured to take advantage of the sublink
style of execution, as seen in recent complaint from Kevin Grittner. Since
the user can get the other behavior by reorganizing his query, having the
flattening happen automatically is just a convenience, and that doesn't
justify breaking existing applications. Eventually it would be nice to
re-enable this, but that seems to require a significantly different approach
to outer joins in the executor.
Modified Files:
--------------
pgsql/src/backend/optimizer/prep:
prepjointree.c (r1.63 -> r1.64)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/prep/prepjointree.c?r1=1.63&r2=1.64)
Tom, you mentioned this should be a TODO item. Do we put it on our main
TODO, and if so, in what section?
---------------------------------------------------------------------------
Tom Lane wrote:
Log Message:
-----------
Temporarily (I hope) disable flattening of IN/EXISTS sublinks that are within
the ON clause of an outer join. Doing so is semantically correct but results
in de-optimizing queries that were structured to take advantage of the sublink
style of execution, as seen in recent complaint from Kevin Grittner. Since
the user can get the other behavior by reorganizing his query, having the
flattening happen automatically is just a convenience, and that doesn't
justify breaking existing applications. Eventually it would be nice to
re-enable this, but that seems to require a significantly different approach
to outer joins in the executor.Modified Files:
--------------
pgsql/src/backend/optimizer/prep:
prepjointree.c (r1.63 -> r1.64)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/prep/prepjointree.c?r1=1.63&r2=1.64)--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
Tom, you mentioned this should be a TODO item. Do we put it on our main
TODO, and if so, in what section?
Optimizer/executor I guess. It's a pretty vague TODO though. We need
some way to consider alternative join orders for joins that do not
semantically commute. When I wrote that CVS log entry I was thinking
in terms of fixing the executor so that the joins actually could
commute, which would involve some way of separating the
force-vars-to-null behavior of an outer join from the actual execution
of the join. I don't know how practical that really is though (and
also I've got a feeling it likely would fall foul of some patent or
other). Or maybe it could be solved entirely in the planner, but I
don't have an idea of what the planner's internal representation would
have to look like to do that.
regards, tom lane
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Tom, you mentioned this should be a TODO item. Do we put it on our main
TODO, and if so, in what section?Optimizer/executor I guess. It's a pretty vague TODO though. We need
some way to consider alternative join orders for joins that do not
semantically commute. When I wrote that CVS log entry I was thinking
in terms of fixing the executor so that the joins actually could
commute, which would involve some way of separating the
force-vars-to-null behavior of an outer join from the actual execution
of the join. I don't know how practical that really is though (and
also I've got a feeling it likely would fall foul of some patent or
other). Or maybe it could be solved entirely in the planner, but I
don't have an idea of what the planner's internal representation would
have to look like to do that.
Yea, this is beyond the detail we normally put in the TODO list. If we
want to add this I am afraid we will need to document other optimizer
items as well.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote:
Yea, this is beyond the detail we normally put in the TODO list. If we
want to add this I am afraid we will need to document other optimizer
items as well.
FWIW you could just add all that text to a subpage of Todo, and point to
it from the regular TODO item. For example the new page could be
Todo/FlattenInExistsSublinks (so it would be a page just for this
particular item).
Or, if you're feeling adventurous, you could name the new page
Todo/OptimizerAndPlanner and move all the items to it, with the same
formatting as the main Todo, and with whatever excruciating detail you
want. Of course, there would still be a pointer to it from the main
Todo.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support