Re: Avoiding a seq scan on a table.

Поиск
Список
Период
Сортировка
От Sean Davis
Тема Re: Avoiding a seq scan on a table.
Дата
Msg-id 264855a00801140925x3208fa30x98ad59547a8679cc@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Avoiding a seq scan on a table.  (LWATCDR <lwatcdr@gmail.com>)
Список pgsql-novice


On Jan 14, 2008 12:14 PM, LWATCDR <lwatcdr@gmail.com> wrote:
Really? From what I have done in writing my own code I have found
hashing to be faster than a btree but then when I wrote my own hashing
it was a specific type of key.
Anyway I put in the tree indexes and I am still getting a seq scan.

Aggregate  (cost=12.12..12.13 rows=1 width=0)
 ->  Result  (cost=0.00..12.12 rows=1 width=0)
       One-Time Filter: NULL::boolean
       ->  Seq Scan on issuetracking  (cost=0.00..12.12 rows=1 width=0)
             Filter: (((issue_target)::text = 'david'::text) OR
((manager)::text = 'david'::text))

The Postgres planner will choose what it thinks is the fastest plan.  In this case, your table has only 1 row (?), so sequential scan will be fastest.  You will want to load data into your table before doing benchmarking.

Sean


В списке pgsql-novice по дате отправления:

Предыдущее
От: "Daniel T. Staal"
Дата:
Сообщение: Re: Avoiding a seq scan on a table.
Следующее
От: Alan Hodgson
Дата:
Сообщение: Re: Avoiding a seq scan on a table.