Re: Window functions, partitioning, and sorting performance - Mailing list pgsql-performance

From Marti Raudsepp
Subject Re: Window functions, partitioning, and sorting performance
Date
Msg-id CABRT9RDUDtH+=Mk7ytML+Ws8Pp0VscgdhzvZphXUr=PrSXVihQ@mail.gmail.com
Whole thread Raw
In response to Re: Window functions, partitioning, and sorting performance  (Eli Naeher <enaeher@gmail.com>)
List 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 by date:

Previous
From: Eli Naeher
Date:
Subject: Re: Window functions, partitioning, and sorting performance
Next
From: Josh Berkus
Date:
Subject: Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3