Hi,
On Wednesday 04 March 2009 02:37:42 Scott Marlowe wrote:
If some oddball query really needs a lot of work_mem,
and benchmarks show something larger work_mem helps, consider raising
the work_mem setting for that one query to something under 1G (way
under 1G) That makes it noticeably
- Scott Marlowe scott.marl...@gmail.com escreveu:
Oh my lord, that is a foot gun waiting to go off. Assuming 2k
connections, and somehow a fair number of them went active with big
sorts, you'd be able to exhaust all physical memory with about 8 to
16 connections. Lower work_mem now. To
You may have decreased performance in your batch jobs with the lower work_mem
setting.
Additionally, the fact that you haven't had swap storm issues so far means that
although there is certain risk of an issue, its probably a lot lower than what
has been talked about here so far.
Without a
On Wed, Mar 4, 2009 at 11:18 AM, Scott Carey sc...@richrelevance.com wrote:
You may have decreased performance in your batch jobs with the lower
work_mem setting.
That would be why I recommended benchmarking queries that need more
memory and setting work_mem for those queries alone.
Hello all
In a dedicated server with 16 cores and 16GB of RAM running PostgreSQL 8.2.5 we
have a database with basically two kinds of transactions:
- short transactions with a couple of updates and inserts that runs all the
day;
- batch data loads with hundreds of inserts that runs several
On Tue, Mar 3, 2009 at 5:28 PM, Flavio Henrique Araque Gurgel
fla...@4linux.com.br wrote:
Hello all
In a dedicated server with 16 cores and 16GB of RAM running PostgreSQL 8.2.5
we have a database with basically two kinds of transactions:
- short transactions with a couple of updates and
Tue, 3 Mar 2009 18:37:42 -0700 -n
Scott Marlowe scott.marl...@gmail.com írta:
Oh my lord, that is a foot gun waiting to go off. Assuming 2k
connections, and somehow a fair number of them went active with big
I absolutely agree with Scott. Plus set effective_cache_size
accordingly, this would
