Re: Planner question

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tom Raney <raneyt(at)cecs(dot)pdx(dot)edu>
Cc: Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Planner question
Date: 2008-09-10 18:41:16
Message-ID: 4159.1221072076@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Raney <raneyt(at)cecs(dot)pdx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2008-09-10 19:30:56 Re: New FSM patch
Previous Message Robert Haas 2008-09-10 18:27:57 Re: Common Table Expressions (WITH RECURSIVE) patch