Re: Window functions, partitioning, and sorting performance

From: Marti Raudsepp <marti(at)juffo(dot)org>
To: Eli Naeher <enaeher(at)gmail(dot)com>
Cc: pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Window functions, partitioning, and sorting performance
Date: 2014-08-21 14:02:07
Message-ID: CABRT9RCmQZm+gFD+gsrGHFmAZ6FXS4tk3gz8roDvpKAowQUbMg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, Aug 21, 2014 at 4:29 PM, Eli Naeher <enaeher(at)gmail(dot)com> wrote:
> Clearly the bulk of the time is spent sorting the rows in the original
> table, and then again sorting the results of the subselect. But I'm afraid I
> don't really know what to do with this information. Is there any way I can
> speed this up?

"Sort Method: external merge Disk: 120976kB"

The obvious first step is to bump up work_mem to avoid disk-based
sort. Try setting it to something like 256MB in your session and see
how it performs then. This may also allow the planner to choose
HashAggregate instead of sort.

It not always straightforward how to tune correctly. It depends on
your hardware, concurrency and query complexity, here's some advice:
https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server#work_mem_maintainance_work_mem

Also you could create an index on (route, direction, stop, stop_time)
to avoid the inner sort entirely.

And it seems that you can move the "INNER JOIN stop" to the outer
query as well, not sure if that will change much.

Try these and if it's still problematic, report back with a new EXPLAIN ANALYZE

Regards,
Marti

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Shaun Thomas 2014-08-21 14:05:41 Re: Window functions, partitioning, and sorting performance
Previous Message Eli Naeher 2014-08-21 13:29:55 Window functions, partitioning, and sorting performance