On Fri, 2006-04-21 at 23:07 -0400, Bruce Momjian wrote:
Where are we on this patch?
Well the patches work and have been performance tested, with results
posted. Again, the title of this thread doesn't precisely describe the
patch any longer.
The question is do people believe there is benefit in
On Sat, Apr 22, 2006 at 01:17:08PM -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I still do, for multi-user systems. Releasing unused memory from a large
CREATE INDEX will allow that memory to be swapped out, even if the brk
point can't be changed.
Say what? It can get
On Sat, 2006-04-22 at 13:17 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I still do, for multi-user systems. Releasing unused memory from a large
CREATE INDEX will allow that memory to be swapped out, even if the brk
point can't be changed.
Say what? It can get swapped
On Sat, Apr 22, 2006 at 06:38:53PM +0100, Simon Riggs wrote:
On Sat, 2006-04-22 at 13:17 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I still do, for multi-user systems. Releasing unused memory from a large
CREATE INDEX will allow that memory to be swapped out, even if the
On Sat, Apr 22, 2006 at 01:14:42PM -0700, David Gould wrote:
To avoid running out of swap and triggering the oom killer we have
had to reduce work_mem below what we prefer.
Dunno about your work_mem, but you can make sure the OOM killer
doesn't kill you as follows
On Sat, Apr 22, 2006 at 01:49:25PM -0700, David Fetter wrote:
On Sat, Apr 22, 2006 at 01:14:42PM -0700, David Gould wrote:
To avoid running out of swap and triggering the oom killer we have
had to reduce work_mem below what we prefer.
Dunno about your work_mem, but you can make sure the
Where are we on this patch?
---
Simon Riggs wrote:
On Tue, 2006-03-21 at 17:47 -0500, Tom Lane wrote:
I'm fairly unconvinced about Simon's underlying premise --- that we
can't make good use of work_mem in sorting
On Wed, 2006-03-22 at 10:03 +, Simon Riggs wrote:
Recent test results show that with a 512MB test sort we can reclaim
97% of memory during final merge with only a noise level (+2%)
increase in overall elapsed time. (Thats just an example, your mileage
may vary). So a large query would use
On Sat, Mar 25, 2006 at 12:24:00PM +, Simon Riggs wrote:
memory. Using too much memory could also impact overall elapsed time
when we have concurrent users, so the question is should we optimise
resources for the multi-user case or for the single user case? Where is
the right balance
On Wed, 2006-03-22 at 07:48 +, Simon Riggs wrote:
On Tue, 2006-03-21 at 17:47 -0500, Tom Lane wrote:
I'm fairly unconvinced about Simon's underlying premise --- that we
can't make good use of work_mem in sorting after the run building phase
--- anyway.
We can make good use of
10 matches
Mail list logo
