Richard Huxton <dev@archonet.com> writes:
> What I don't understand is the seq-scan on companies.co_id since it has a
> unique index on it and *can't* match more than once for a given row while
> looping through orders.
Since the table is evidently only 2 pages long, the planner figures it's
cheaper to read it all than to touch both the index and the table.
The hole in this logic is that the cost estimate is made without regard
for the fact that we're scanning the table repeatedly, and so at least
the first few levels of index are likely to stay swapped in. I have
some ideas about how to improve that, but dunno if it'll get done for
7.3. In the meantime you might try reducing random_page_cost to see if
you like the results better.
regards, tom lane