Re: self join revisited

Поиск
Список
Период
Сортировка
От Matthew Wakeling
Тема Re: self join revisited
Дата
Msg-id alpine.DEB.2.00.0904011743290.21772@aragorn.flymine.org
обсуждение исходный текст
Ответ на self join revisited  (Rikard Pavelic <rikard.pavelic@zg.htnet.hr>)
Список pgsql-performance
On Wed, 1 Apr 2009, Rikard Pavelic wrote:
> It would be great if Postgres could rewrite this query
>
> SELECT bt1.id, bt1.total, sq.id, sq.total
> FROM
>     big_table bt1
>     INNER JOIN small_table st1 on st1.big_id = bt1.id
>     INNER JOIN
>     (
>         SELECT bt2.id, st2.total
>         FROM
>             big_table bt2
>             INNER JOIN small_table st2 on st2.big_id = bt2.id
>         WHERE
>             st2.total > 100
>     ) sq ON sq.id = bt1.id
> WHERE
>     st1.total<200
>
> like this
>
> SELECT bt1.id, bt1.total, bt1.id, st2.total
> FROM
>     big_table bt1
>     INNER JOIN small_table st1 on st1.big_id = bt1.id
>     INNER JOIN small_table st2 on st2.big_id = bt1.id AND st2.total > 100
> WHERE
>     st1.total<200

Those queries are only equivalent if big_table.id is unique. However, even
so some benefit could be gained from a self-join algorithm. For instance,
if given some rather evil cleverness, it could be adapted to calculate
overlaps very quickly.

However, a self-join is very similar to a merge join, and the benefit over
a standard merge join would be small.

Matthew

--
"We did a risk management review.  We concluded that there was no risk
 of any management."        -- Hugo Mills <hugo@carfax.nildram.co.uk>

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

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: Raid 10 chunksize
Следующее
От: Stef Telford
Дата:
Сообщение: Re: Raid 10 chunksize