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 по дате отправления: