Re: Seq Scan

Поиск
Список
Период
Сортировка
От Tyler Durden
Тема Re: Seq Scan
Дата
Msg-id ab07320e0706011017u55ceacd8tb428b89128a53975@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Seq Scan  ("John D. Burger" <john@mitre.org>)
Ответы Re: Seq Scan  (Kevin Hunter <hunteke@earlham.edu>)
Список pgsql-general
Yes,  either case happens the same.
I'm come recently from MySQL and it works in a different way.
I find strange that a simple SELECT COUNT(...) is so slow with only
700 000 records.
Has been a nightmare optimizing this tables/queries.
Sorry about this silly question, but I'm new to Posgresql.

Thanks,
Tyler

On 6/1/07, John D. Burger <john@mitre.org> wrote:
> You mention SELECT COUNT(ID), but your example shows SELECT ID.  In
> either case, the planner is choosing the correct plan.  Indexes exist
> to save the engine from visiting every row in the table, but both of
> these queries require every row to be visited anyway.
>
> Perhaps you think that these queries can be satisfied without
> visiting the actual table rows at all, using only the index.  This is
> incorrect - PG doesn't work that way.
>
> - John Burger
>    MITRE
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

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

Предыдущее
От: Mike Ginsburg
Дата:
Сообщение: Interval Rounding
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Looking for Graphical people for PostgreSQL tradeshow signage