> "Mark Woodward" <[EMAIL PROTECTED]> writes: >> Again, regardless of OS used, hashagg will exceed "working memory" as >> defined in postgresql.conf. > > So? If you've got OOM kill enabled, it can zap a process whether it's > strictly adhered to work_mem or not. The OOM killer is entirely capable > of choosing a victim process whose memory footprint hasn't changed > materially since it started (eg, the postmaster).
Sorry, I must strongly disagree here. The postgresql.conf "working mem" is a VERY IMPORTANT setting, it is intended to limit the consumption of memory by the postgresql process. Often times PostgreSQL will work along side other application servers on the same system, infact, may be a sub-part of application servers on the same system. (This is, in fact, how it is used on one of my site servers.) Clearly, if the server will use 1000 times this number (Set for 1024K, but exceeds 1G) this is broken, and it may cause other systems to fail or perform very poorly. If it is not something that can be fixed, it should be clearly documented. ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match