From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Zotov <zotov(at)oe-it(dot)ru>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Query optimization problem |
Date: | 2010-07-20 15:23:07 |
Message-ID: | 87wrsq9nz8.fsf@hi-media-techno.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> All that having been said, I think the issue here is that the query
> planner isn't inferring that d1.ID=<some constant> implies d2.ID=<some
> constant>, even though there's a join clause d1.ID=d2.ID.
I think that's what the Equivalence Classes are for. Or at least that's
what they do in my head, not forcibly in the code.
The specific diff between the two queries is :
JOIN DocPrimary d2 ON d2.BasedOn=d1.ID
- WHERE (d1.ID=234409763) or (d2.ID=234409763)
+ WHERE (d2.BasedOn=234409763) or (d2.ID=234409763)
So the OP would appreciate that the planner is able to consider applying
the restriction on d2.BasedOn rather than d1.ID given that d2.BasedOn is
the same thing as d1.ID, from the JOIN.
I have no idea if Equivalence Classes are where to look for this, and if
they're meant to extend up to there, and if that's something possible or
wise to implement, though.
Regards,
--
dim
From | Date | Subject | |
---|---|---|---|
Next Message | David Christensen | 2010-07-20 15:23:18 | Re: Explicit psqlrc |
Previous Message | Dave Page | 2010-07-20 15:08:39 | Solaris Sparc - dblink regression test failure |