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?

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

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

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