Re: self join revisited

From: Matthew Wakeling <matthew(at)flymine(dot)org>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: self join revisited
Date: 2009-04-01 16:46:04
Message-ID: alpine.DEB.2.00.0904011743290.21772@aragorn.flymine.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)carfax(dot)nildram(dot)co(dot)uk>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Stef Telford 2009-04-01 16:48:58 Re: Raid 10 chunksize
Previous Message Scott Marlowe 2009-04-01 16:41:48 Re: Raid 10 chunksize