Re: 2 left joins causes seqscan

> 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 challenge for it.
>

The point that i was trying to make by doing 2 queries and unioning them
is, that it is faster to use 2 index scans than to use sequential scans.
I can't quite recognize the challenge that i'm posing the query planner,
but i am willing/hoping to learn more about it.

AFAIK, the planner has some statistics about the frequencies in which
values in the columns occur. That way, it can calculate the approx number
of records that will have to be fetched and considering the latency of a
rotating hard disk, it can calculate what is likely to be faster: a
sequential scan or using the index for random reads.

In this case, the planner can calculate the number of records that need to
be fetched from B, in my case it says it expects 4 of them in both cases.
Combined, it would fetch max 8 records from B, in contrast to 40K or even
twice that.
I can't understand what is confusing the planner.

Cheers,

Willy-Bas