Richard Neill <rn214@cam.ac.uk> wrote:
> I'd expect the ORDER BY to be the last thing that runs
> Nested Loop Left Join (cost=0.00..727737158.77
> rows=806903677108 width=195) (actual time=31739.052..32862.322
> rows=15 loops=1)
It probably would if it knew there were going to be 15 rows to sort.
It is estimating that there will be 806,903,677,108 rows, in which
case it thinks that using the index will be faster. The question is
why it's 10 or 11 orders of magnitude off on the estimate of result
rows. Could you show us the table definitions underlying that view?
-Kevin
