Message-ID: <55842DF1.9040208@intuvisiontech.com>
Date: Fri, 19 Jun 2015 10:57:53 -0400
From: Ian Pushee <ian@intuvisiontech.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: Slow query (planner insisting on using 'external merge' sort
 type)
References: <55842859.4060102@intuvisiontech.com>
 <1405767375.375868.1434725229563.JavaMail.open-xchange@oxweb02.ims-firmen.de>
In-Reply-To: 
 <1405767375.375868.1434725229563.JavaMail.open-xchange@oxweb02.ims-firmen.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org


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.

Thanks,
-Ian


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance