Re: Window functions, partitioning, and sorting performance

Поиск
Список
Период
Сортировка
От Marti Raudsepp
Тема Re: Window functions, partitioning, and sorting performance
Дата
Msg-id CABRT9RDUDtH+=Mk7ytML+Ws8Pp0VscgdhzvZphXUr=PrSXVihQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Window functions, partitioning, and sorting performance  (Eli Naeher <enaeher@gmail.com>)
Список pgsql-performance
On Thu, Aug 21, 2014 at 7:19 PM, Eli Naeher <enaeher@gmail.com> wrote:
> However, when I try to do a
> test self-join using it, Postgres does two seq scans across the whole table,
> even though I have indexes on both id and previous_stop_event:
> http://explain.depesz.com/s/ctck. Any idea why those indexes are not being
> used?

Because the planner thinks seq scan+hash join is going to be faster
than incurring the overhead of index scans for other kinds of plans.

You can try out alternative plan types by running 'set
enable_hashjoin=off' in your session. If it does turn out to be
faster, then it usually means you haven't set planner tunables right
(random_page_cost, effective_cache_size and possibly cpu_tuple_cost).

Regards,
Marti


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

Предыдущее
От: Eli Naeher
Дата:
Сообщение: Re: Window functions, partitioning, and sorting performance
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3