From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Ian Pushee <ian@intuvisiontech.com>
To: pgsql-performance@postgresql.org
Subject: Re: Slow query (planner insisting on using 'external merge' sort type)
Date: Tue, 23 Jun 2015 16:05:13 -0500
Message-ID: <5589CA09.8030608@BlueTreble.com> (raw)
In-Reply-To: <55842DF1.9040208@intuvisiontech.com>
References: <55842859.4060102@intuvisiontech.com>
<1405767375.375868.1434725229563.JavaMail.open-xchange@oxweb02.ims-firmen.de>
<55842DF1.9040208@intuvisiontech.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
On 6/19/15 9:57 AM, Ian Pushee wrote:
>
>
> On 6/19/2015 10:47 AM, Andreas Kretschmer wrote:
>>> Explain Analyze outputs (links as requested):
>>> Default plan: http://explain.depesz.com/s/ib3k
>>> Forced index (random_page_cost=1.0): http://explain.depesz.com/s/lYaP
>>>
>>> Software/Hardware: PGSql 9.2.1, Windows 8.1, 8GB RAM
>>> All pgsql settings are at their defaults.
>> increase work_mem. per session via set work_mem = 'xxxMB'; or in
>> postgresql.conf, reload.
>>
>>
>
> Hi Andreas,
>
> The number of rows in the events table isn't constrained, so
> unfortunately it isn't feasible to set work_mem high enough to allow an
> in-memory sort. Forcing the planner to use the index works to produce a
> fast query, so I'm wondering if there is a more general way to getting
> the planner to take into account that work_mem isn't big enough to fit
> the query which will result in a MUCH more costly external merge.
What Andreas is saying is the reason the sort is so expensive is because
it spilled to disk. If you don't have enough memory to do the sort
in-memory, then you probably don't have enough memory to buffer the
table either, which means the index scan is going to be a LOT more
expensive than a sort.
That said, the better your IO system is the lower you need to set
random_page_cost. With a good raid setup 2.0 is a good starting point,
and I've run as low as 1.1. I've never run a system on all SSD, but I've
heard others recommend setting it as low as 1.0 on an all SSD setup.
It's also worth noting that there's some consensus that the optimizer is
generally too eager to switch from an index scan to a seqscan.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: Jim.Nasby@BlueTreble.com, ian@intuvisiontech.com
Subject: Re: Slow query (planner insisting on using 'external merge' sort type)
In-Reply-To: <5589CA09.8030608@BlueTreble.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox