Re: Query Optimizer makes a poor choice

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: Query Optimizer makes a poor choice
Дата
Msg-id CAOR=d=1_=UJ2QV7Q7LDjtsS1rT-OgNL_Jj43ynk10DNzJ1sfnA@mail.gmail.com
обсуждение исходный текст
Ответ на Query Optimizer makes a poor choice  ("Tyler Hains" <thains@profitpointinc.com>)
Ответы Re: Query Optimizer makes a poor choice  ("Tyler Hains" <thains@profitpointinc.com>)
Re: Query Optimizer makes a poor choice  (Tomas Vondra <tv@fuzzy.cz>)
Список pgsql-general
On Tue, Nov 29, 2011 at 11:21 AM, Tyler Hains <thains@profitpointinc.com> wrote:
> # explain analyze select * from cards where card_set_id=2850 order by
> card_id limit 1;
>                                                                QUERY PLAN
>
-----------------------------------------------------------------------------------------------------------------------------------------
>  Limit  (cost=0.00..105.19 rows=1 width=40) (actual time=6026.947..6026.948
> rows=1 loops=1)
>    ->  Index Scan using cards_pkey on cards  (cost=0.00..2904875.38
> rows=27616 width=40) (actual time=6026.945..6026.945 rows=1 loops=1)

There's a huge disconnect here between what the query planner expects
(27k rows) and how many there are (1).  Also, getting a single row
from an index should be faster than this, even if the table and index
are quite large.  Have you checked for bloat on this index?

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

Предыдущее
От: Filip Rembiałkowski
Дата:
Сообщение: Re: Extending the volume size of the data directory volume
Следующее
От: MURAT KOÇ
Дата:
Сообщение: DDL & DML Logging doesn't work for calling functions