| From: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
|---|---|
| To: | "Decibel!" <decibel(at)decibel(dot)org> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: configurability of OOM killer |
| Date: | 2008-02-05 21:54:17 |
| Message-ID: | 47A8DB09.6000803@cheapcomplexdevices.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Decibel! wrote:
>
> Yes, this problem goes way beyond OOM. Just try and configure
> work_memory aggressively on a server that might see 50 database
> connections, and do it in such a way that you won't swap. Good luck.
That sounds like an even broader and more difficult problem
than managing memory.
If you have 50 connections that all want to perform large sorts,
what do you want to have happen?
a) they each do their sorts in parallel with small amounts
of memory for each; probably all spilling to disk?
b) they each get a big chunk of memory but some have to
wait for each other?
c) something else?
Seems (a)'s already possible today with setting small work_mem.
Seems (b)'s already possible today with a larger work_mem and
pg_pool.
Stepping back from the technical details, what do you think
should happen. (though perhaps it should be taken to a different
thread)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ron Mayer | 2008-02-05 21:56:48 | Re: Feature Freeze Date for Next Release |
| Previous Message | Dave Page | 2008-02-05 21:47:16 | Re: [BUGS] BUG #3909: src\tools\msvc\clean.bat clears parse.h file |