Re: Planner question

Tom Lane wrote:
> Tom Raney <raneyt@cecs.pdx.edu> writes:
>> Why does the index scan for tenk1 include a path key from 
>> onek.unique2?  Is it implying an equivalence there?
> 
>> bench=# explain select * from tenk1 JOIN onek ON 
>> tenk1.unique2=onek.unique2;
> 
> Yes, for an example like that the planner knows that tenk1.unique2 and
> onek.unique2 will have equal values in any valid join row, so it's okay
> to suppose that a sort by one is the same as a sort by the other.  So
> the pathkey items actually reference sets of variables
>     {tenk1.unique2, onek.unique2}
> not just individual variables.

Thanks.

> 
>> RELOPTINFO (tenk1): rows=10000 width=244
>>          path list:
>>          SeqScan(tenk1) rows=10000 cost=0.00..434.00
>>          IdxScan(tenk1) rows=10000 cost=0.00..583.25
>>            pathkeys: ((tenk1.unique2, onek.unique2))  <---
> 
>>          cheapest startup path:
>>          SeqScan(tenk1) rows=10000 cost=0.00..434.00
> 
>>          cheapest total path:
>>          SeqScan(tenk1) rows=10000 cost=0.00..434.00
> 
> Hm, I don't recognize this output format, is it coming from some custom
> code?

Yes, it is.  I thought it was easier to read the OPTIMIZER_DEBUG 
output with the relation names instead of the relation indexes.  I 
will post a patch against CVS HEAD if you think it will help others.

-Tom