We re-tested these settings a few times after our initial test and realized that the execution time I posted was shewed, because the execution plan was cached after the initial run. Subsequent executions ran in a little over a second.
There ended up being no significant saving by setting these parameters. Un-cached the query ran in about 55 seconds.
-------- Original Message --------
Subject: Re: [GENERAL] Very slow inner join query Unacceptable
latency.
From: Scott Marlowe <scott.marlowe@xxxxxxxxx>
Date: Fri, May 24, 2013 3:03 pm
To: fburgess@xxxxxxxxxxxxxxx
Cc: Jaime Casanova <jaime@xxxxxxxxxxxxxxx>, psql performance list
<pgsql-performance@xxxxxxxxxxxxxx>, Postgres General
<pgsql-general@xxxxxxxxxxxxxx>
On Fri, May 24, 2013 at 3:44 PM, <fburgess@xxxxxxxxxxxxxxx> wrote:
> Total runtime: 1606.728 ms 1.6 seconds <- very good response time
> improvement
>
> (7 rows)
>
> Questions:
>
> Any concerns with setting these conf variables you recommended; work_mem,
> random_page_cost dbserver wide (in postgresql,conf)?
>
> Thanks so much!!!
Yes 500MB is pretty high especially if you have a lot of connections.
Try it with it back down to 16MB and see how it does. Work mem is per
sort so a setting as high as 500MB can exhaust memory on the machine
under heavy load.
--
To understand recursion, one must first understand recursion.
