Re: Planner question - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Planner question
Date
Msg-id 4159.1221072076@sss.pgh.pa.us
Whole thread Raw
In response to Re: Planner question  (Tom Raney <raneyt@cecs.pdx.edu>)
Responses Re: Planner question  (Tom Raney <raneyt@cecs.pdx.edu>)
List pgsql-hackers
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.

> 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


pgsql-hackers by date:

Previous
From: "Robert Haas"
Date:
Subject: Re: Common Table Expressions (WITH RECURSIVE) patch
Next
From: Zdenek Kotala
Date:
Subject: Re: New FSM patch