Re: [COMMITTERS] pgsql: Temporarily (I hope) disable flattening of IN/EXISTS sublinks
От | Bruce Momjian |
---|---|
Тема | Re: [COMMITTERS] pgsql: Temporarily (I hope) disable flattening of IN/EXISTS sublinks |
Дата | |
Msg-id | 200903281928.n2SJSXB15081@momjian.us обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Temporarily (I hope) disable flattening of IN/EXISTS sublinks (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Temporarily (I hope) disable
flattening of IN/EXISTS sublinks
|
Список | pgsql-hackers |
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. +
В списке pgsql-hackers по дате отправления: