Thread: Re: [COMMITTERS] pgsql: Temporarily (I hope) disable flattening of IN/EXISTS sublinks
Re: [COMMITTERS] pgsql: Temporarily (I hope) disable flattening of IN/EXISTS sublinks
From
Tom Lane
Date:
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
Re: [COMMITTERS] pgsql: Temporarily (I hope) disable flattening of IN/EXISTS sublinks
From
Bruce Momjian
Date:
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. +
Re: Re: [COMMITTERS] pgsql: Temporarily (I hope) disable flattening of IN/EXISTS sublinks
From
Alvaro Herrera
Date:
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