Index Scan Backward

Здравствуейте.

Обнаружил интересную особенность планировщика.

Имеем запрос вида:
---
SELECT
  a.id, a.title, a.abstract
FROM
  article AS a,
  topic AS t
WHERE
  t.trail ~ 'root.carper.article.!basin|competition'
  AND a.topic = t.id
ORDER BY
  a.start DESC
LIMIT 1;

Время отдачи ~ 400мс

EXPLAIN:
---
                                                    QUERY PLAN
-------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.00..2638.38 rows=1 width=89)
   ->  Nested Loop  (cost=0.00..184686.59 rows=70 width=89)
         ->  Index Scan *Backward* using article_start_idx on article a
 (cost=0.00..141435.14 rows=71184 width=93)
         ->  Index Scan using _topic_pkey on topic t  (cost=0.00..0.60
rows=1 width=4)
               Index Cond: (a.topic = t.id)
               Filter: (trail ~
'root.carper.article.!basin|competition'::lquery)
(6 rows)


Как видно из explain, в наличии Backward Index Scan, до фильтрации по
топику, по, практически, всем "статьям".

Если убрать "LIMIT 1", мы получим нормальное ожидаемое поведение ( как
мне кажется ) - статьи отфильтрованные по topic.id и отсортированные в
обратном порядке по да "дате начала".

Почему, в случае с LIMIT, планировщик сначала решил вытащить все статьи,
 отсортировать их, а уж затем фильтровать по topic.id?

Или что-то в у меня не так?

Заранее - спасибо!

--
С уважением,
Алексей Заяц.