Skip site navigation (1) Skip section navigation (2)

Index Scan Backward

From: Zayats Alexey <az(at)antora(dot)ru>
To: pgsql-ru-general(at)postgresql(dot)org
Subject: Index Scan Backward
Date: 2008-03-03 12:03:01
Message-ID: 47CBE8F5.5080205@antora.ru (view raw or flat)
Thread:
Lists: pgsql-ru-general
Здравствуейте.

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

Имеем запрос вида:
---
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?

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

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

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

pgsql-ru-general by date

Next:From: Maxim BogukDate: 2008-03-03 12:19:02
Subject: Запрос к авторам GIN/GIST индексов
Previous:From: Dmitriy MiksIrDate: 2008-02-21 16:56:37
Subject: Re: Аналог distinct для массива

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group