Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins
Дата
Msg-id 200002062243.RAA07995@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I thought "t1.v1 = t2.v2" would be in t1 RelOptInfo and t2 RelOptInfo. 
> > Of course, this is a join info restriction, not a restrict info
> > restriction.
> 
> Right, it would appear in t1's joininfo list (showing t2 as unjoined_relids)
> and in t2's joininfo list (showing t1 as unjoined_relids).  Then when
> we make a join rel from t1 + t2, the clause would be put into that rel's
> restrictinfo list, since it's no longer a joining clause for the
> joinrel; but it does need to be implemented at the time of the join.
> (The bug is probably only visible for auxiliary quals that are not
> being used as the driving clause of the join method; they need to show
> up in the qpquals of the final plan, or they won't get enforced.)

I understand.  Is it only non-equi-joins that show this, where the join
is actually also a restriction in a sense.


--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins
Следующее
От: Emmanuel Charpentier
Дата:
Сообщение: Case sensitivity issues