Re: order of nested loop

Tom Lane wrote:

>
> That scan is estimated to yield 5446 rows and it only yields 1.  Do you
> have any idea why the estimate is so far off?  (My guess is that podkey,
> status and banned are correlated to a large extent, but you tell us.)

The relationship between d and u is like this: There is a row in d for
each user, and for each pod they are a member of there is an entry in u.
  So when I'm querying u for members of a particular pod I'm filtering
by the status of the d entry and that status of the u entry.  There are
a lot of entries in d, but only a few of them will be members of a
particular pod.  Thus it would make sense to first get the entries in u,
filter them, then filter by their status in d.  There will be an entry
in d for each entry in u, but not vice versa.

The planner shows this for the scan on d:
(cost=0.00..2380577.42 rows=525568 width=49)

Maybe it thinks it will reach the limit of 25 before it actually does,
which is why it is willing to try something so expensive?