| From: | Ian Pushee <ian(at)intuvisiontech(dot)com> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Slow query (planner insisting on using 'external merge' sort type) |
| Date: | 2015-06-19 14:57:53 |
| Message-ID: | 55842DF1.9040208@intuvisiontech.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Igor Neyman | 2015-06-19 15:06:37 | Re: Slow query (planner insisting on using 'external merge' sort type) |
| Previous Message | Ian Pushee | 2015-06-19 14:53:43 | Re: Slow query (planner insisting on using 'external merge' sort type) |