От: Ľubomír Varga
Тема: Some question
Дата: ,
Msg-id: 201003311746.38192.luvar@plaintext.sk
(см: обсуждение, исходный текст)
Ответы: Re: Some question  (Scott Marlowe)
Re: Some question  ("Kevin Grittner")
Список: pgsql-performance

Скрыть дерево обсуждения

Some question  (Ľubomír Varga, )
 Re: Some question  (Scott Marlowe, )
  Re: Some question  (Yeb Havinga, )
 Re: Some question  ("Kevin Grittner", )
  Re: Some question  (Ľubomír Varga, )
 Re: Some question  ("Kevin Grittner", )

Hi, stright to my "problem":

SELECT * FROM t_route
    WHERE t_route.route_type_fk = 1
    limit 4;

"Limit  (cost=0.00..0.88 rows=4 width=2640)"
"  ->  Seq Scan on t_route  (cost=0.00..118115.25 rows=538301 width=2640)"
"        Filter: (route_type_fk = 1)"

If I try to select constant 1 from table with two rows, it will be something
like this:

SELECT * FROM t_route
    WHERE t_route.route_type_fk = (SELECT id FROM t_route_type WHERE type = 2)
    limit 4;

"Limit  (cost=1.02..1.91 rows=4 width=2640)"
"  InitPlan"
"    ->  Seq Scan on t_route_type  (cost=0.00..1.02 rows=1 width=8)"
"          Filter: ("type" = 2)"
"  ->  Seq Scan on t_route  (cost=0.00..118115.25 rows=535090 width=2640)"
"        Filter: (route_type_fk = $0)"

First query is done in about milicesonds. Second is longer than 60 seconds.
t_route is bigger table (~10M rows).

I think that it seq scans whole table. Is it bug? If no, how can I achieve
that second select will not take time to end of world...

Have a nice day and thanks for any reply.

Odborník na všetko je zlý odborník. Ja sa snažím byť výnimkou potvrdzujúcou

В списке pgsql-performance по дате сообщения:

От: Samuel Gendler
Сообщение: indexes in partitioned tables - again
От: Robert Haas
Сообщение: Re: LIMIT causes planner to do Index Scan using a less optimal index