From: | Tobias Brox <tobias(at)nordicbet(dot)com> |
---|---|
To: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
Cc: | Tobias Brox <tobias(at)nordicbet(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Swappiness setting on a linux pg server |
Date: | 2006-10-19 17:10:23 |
Message-ID: | 20061019171023.GA29574@oppetid.no |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
[Jim C. Nasby - Thu at 12:00:39PM -0500]
> What's reasonable for work_mem depends on your workload. If you've got
> some reporting queries that you know aren't run very concurrently they
> might benefit from large values of work_mem. For stats.distributed.net,
> I set work_mem to something like 2MB in the config file, but the nightly
> batch routines manually set it up to 256M or more, because I know that
> those only run one at a time, and having that extra memory means a lot
> of stuff that would otherwise have to spill to disk now stays in memory.
That sounds like a good idea; indeed we do have some few heavy reporting
queries and they are not run much concurrently (the application checks
the pg_stat_activity table and will disallow reports to be taken out if
there is too much activity there). We probably would benefit from
raising the work mem just for those reports, and lower it for the rest
of the connections.
From | Date | Subject | |
---|---|---|---|
Next Message | Tobias Brox | 2006-10-19 17:12:58 | Re: Swappiness setting on a linux pg server |
Previous Message | Jens Schipkowski | 2006-10-19 17:05:22 | Re: DB Performance decreases due to often written/accessed table |