Tom Lane wrote:
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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
