Search Postgresql Archives

Re: [PERFORM] Very slow inner join query Unacceptable latency.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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: [PERFORM] 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.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux