Richard Neill <rn214@xxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
