From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Edison Azzi <edisonazzi(at)terra(dot)com(dot)br> |
Cc: | Richard Huxton <dev(at)archonet(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Join the same row |
Date: | 2005-12-11 20:36:25 |
Message-ID: | 18628.1134333385@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Edison Azzi <edisonazzi(at)terra(dot)com(dot)br> writes:
> You are rigth, the planner will not eliminate the join, see:
> select * from cta_pag a, cta_pag p where a.nrlancto=p.nrlancto and
> p.nrlancto = 21861;
> EXPLAIN:
> Nested Loop (cost=0.00..11.48 rows=1 width=816)
> -> Index Scan using cta_pag_pk on cta_pag a (cost=0.00..5.74 rows=1
> width=408)
> Index Cond: (21861::numeric = nrlancto)
> -> Index Scan using cta_pag_pk on cta_pag p (cost=0.00..5.74 rows=1
> width=408)
> Index Cond: (nrlancto = 21861::numeric)
But do you care? That second fetch of the same row isn't going to cost
much of anything, since everything it needs to touch will have been
sucked into cache already. I don't really see the case for adding logic
to the planner to detect this particular flavor of badly-written query.
Notice that the planner *is* managing to propagate the constant
comparison to both relations.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-12-11 20:38:54 | Re: Should Oracle outperform PostgreSQL on a complex multidimensional query? |
Previous Message | Michael Fuhr | 2005-12-11 19:44:43 | Re: How much expensive are row level statistics? |