From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins |
Date: | 2000-02-06 22:43:52 |
Message-ID: | 200002062243.RAA07995@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Emmanuel Charpentier | 2000-02-06 22:51:34 | Case sensitivity issues |
Previous Message | Tom Lane | 2000-02-06 22:39:11 | Re: [HACKERS] Optimizer cleanup to avoid redundant work on joins |