Re: Performance improvement for joins where outer side is unique

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Performance improvement for joins where outer side is unique
Дата
Msg-id 14475.1457799931@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Performance improvement for joins where outer side is unique  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers
David Rowley <david.rowley@2ndquadrant.com> writes:
> On 12 March 2016 at 11:43, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I wondered why, instead of inventing an extra semantics-modifying flag,
>>> we couldn't just change the jointype to *be* JOIN_SEMI when we've
>>> discovered that the inner side is unique.

> The thing that might matter is that, this;

> explain (costs off) select * from t1 inner join t2 on t1.id=t2.id
>          QUERY PLAN
> ------------------------------
>  Hash Join
>    Hash Cond: (t1.id = t2.id)
>    ->  Seq Scan on t1
>    ->  Hash
>          ->  Seq Scan on t2

> could become;

>           QUERY PLAN
> ------------------------------
>  Hash Semi Join
>    Hash Cond: (t1.id = t2.id)
>    ->  Seq Scan on t1
>    ->  Hash
>          ->  Seq Scan on t2

> Wouldn't that cause quite a bit of confusion?

Well, no more than was introduced when we invented semi joins at all.

> Now, we could get around that by
> adding JOIN_SEMI_INNER I guess, and just displaying that as a normal
> inner join, yet it'll behave exactly like JOIN_SEMI!

I'm not that thrilled with having EXPLAIN hide real differences in the
plan from you; if I was, I'd have just lobbied to drop the "unique inner"
annotation from EXPLAIN output altogether.

(I think at one point we'd discussed displaying this in EXPLAIN output
as a different join type, and I'd been against it at the time.  What
changed my thinking was realizing that it could be mapped on to the
existing jointype "semi join".  We still need one new concept,
"outer semi join" or whatever we decide to call it, but it's less of
a stretch than I'd supposed originally.)
        regards, tom lane



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

Предыдущее
От: Salvador Fandiño
Дата:
Сообщение: Re: Perl's newSViv() versus 64-bit ints?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Perl's newSViv() versus 64-bit ints?