Tom Raney <[EMAIL PROTECTED]> 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. > 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? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers