Re: Outer join query plans and performance

Поиск
Список
Период
Сортировка
От Rich Doughty
Тема Re: Outer join query plans and performance
Дата
Msg-id 435F3F6C.3070203@opusvl.com
обсуждение исходный текст
Ответ на Re: Outer join query plans and performance  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
Tom Lane wrote:
> Rich Doughty <rich@opusvl.com> writes:
>
>>Tom Lane wrote:
>>
>>>The reason these are different is that the second case constrains only
>>>the last-to-be-joined table, so the full cartesian product of t and h1
>>>has to be formed.  If this wasn't what you had in mind, you might be
>>>able to rearrange the order of the LEFT JOINs, but bear in mind that
>>>in general, changing outer-join ordering changes the results.  (This
>>>is why the planner won't fix it for you.)
>
>
>>FWIW mysql 4.1 (and i'm no fan at all of mysql) completes both these queries
>>in approximately 3 seconds.
>
>
> Does mysql get the correct answer, though?  It's hard to see how they do
> this fast unless they (a) are playing fast and loose with the semantics,
> or (b) have very substantially more analysis logic for OUTER JOIN semantics
> than we do.  Perhaps mysql 5.x is better about this sort of thing, but
> for 4.x I'd definitely find theory (a) more plausible than (b).

i would assume so. i'll re-run my testcase later and verify the results of the
two side-by-side.

> The cases that would be interesting are those where rearranging the
> outer join order actually does change the correct answer --- it may not
> in this particular case, I haven't thought hard about it.  It seems
> fairly likely to me that they are rearranging the join order here, and
> I'm just wondering whether they have the logic needed to verify that
> such a transformation is correct.
>
>             regards, tom lane
>


--

   - Rich Doughty

В списке pgsql-performance по дате отправления:

Предыдущее
От: Jean-Max Reymond
Дата:
Сообщение: Re: blue prints please
Следующее
От: "Steinar H. Gunderson"
Дата:
Сообщение: Re: zero performance on query