On Fri, Sep 12, 2014 at 11:11 PM, Kevin Grittner wrote:
>
> The equivalent of your first query is to take the result sets from
> these two queries:
>
> select a1.field1, b1.title, b2.title
> from a a1
> join b b1 on b1.id = a1.id and b1.lang = 1
> left join b b2 on (b2.id = a1.id and b2.lan
On Sun, Sep 14, 2014 at 3:23 PM, Kevin Grittner wrote:
> The fact that the
> first query was complex enough that *you* weren't able to
> accurately optimize it better before posting is pretty good
> evidence that it's moving into the realm of "expensive to
> optimize".
>
>
Touche
BTW i don't mean
Kevin Grittner writes:
> Willy-Bas Loos wrote:
>> I can't understand what is confusing the planner.
> Well, it doesn't do exhaustive proofs of whether two queries are
> equivalent. If it did, it would still not have come up with a plan
> like your second one, because it is not equivalent.
Yeah
Willy-Bas Loos wrote:
> I can't understand what is confusing the planner.
Well, it doesn't do exhaustive proofs of whether two queries are
equivalent. If it did, it would still not have come up with a plan
like your second one, because it is not equivalent. The trick in
planning is to stop whe
> But the two queries don't return the same results. Of course the
> second one will be faster.
> The equivalent of your first query is to take the result sets from
> these two queries
(...)
> it's not
> too surprising that the planner can't come up with the optimal
> plan; you've posed quite a
Willy-Bas Loos wrote:
> As you can see, the second query is far more efficient, even
> though it scans both tables twice to combine the results.
But the two queries don't return the same results. Of course the
second one will be faster. The simple equivalent of your second
query is:
explain a
