Re: OUTER JOIN performance regression remains in 8.3beta4

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: OUTER JOIN performance regression remains in 8.3beta4
Дата
Msg-id 871w8qlt0c.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: OUTER JOIN performance regression remains in 8.3beta4  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: OUTER JOIN performance regression remains in 8.3beta4  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> As an example, consider
>     t1 join t2 on (...) join t3 on (...) ... join t8 on (...)
> and for simplicity suppose that each ON condition relates the new
> table to the immediately preceding table, and that we can't derive
> any additional join conditions through transitivity.  

So the problem is that if we happen to have some x=<const> clause for any
variable listed in those join clauses then we drop that clause entirely and
end up delaying that join until the very end?

So is the fact that the user provided a useless clause the only information we
have that these tables might be related?

So if I write (along with some other joins):
t1 join t2 on (t1.x=t2.x) where t1.x=3

I'll get a different result than if I write
t1, t2 where t1.x=3 and t2.x=3

?

Perhaps we could be going the other direction and trying to add redundant
selectivity 1.0 clauses when we have multiple variables which come out to the
same value?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication
support!


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

Предыдущее
От: Gavin Sherry
Дата:
Сообщение: Re: Dynamic Partitioning using Segment Visibility Maps
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Problem with CVS HEAD's handling of mergejoins