Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 4F87CB5DBC5 for ; Mon, 12 Sep 2011 22:13:34 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 50879-09 for ; Tue, 13 Sep 2011 01:13:28 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from tamriel.snowman.net (tamriel.snowman.net [72.66.115.51]) by mail.postgresql.org (Postfix) with ESMTP id E7D66B5DBD1 for ; Mon, 12 Sep 2011 22:13:27 -0300 (ADT) Received: by tamriel.snowman.net (Postfix, from userid 1000) id E662B22909; Mon, 12 Sep 2011 21:13:27 -0400 (EDT) Date: Mon, 12 Sep 2011 21:13:27 -0400 From: Stephen Frost To: Robert Schnabel Cc: Scott Marlowe , pgsql-performance Subject: Re: Allow sorts to use more available memory Message-ID: <20110913011327.GT12765@tamriel.snowman.net> References: <4E6E426D.7060405@missouri.edu> <4E6E830E.30701@missouri.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lbYR4+J2RcKO0WXU" Content-Disposition: inline In-Reply-To: <4E6E830E.30701@missouri.edu> X-Editor: Vim http://www.vim.org/ X-Info: http://www.snowman.net X-Operating-System: Linux/2.6.32-5-amd64 (x86_64) X-Uptime: 21:00:35 up 222 days, 9:30, 11 users, load average: 0.06, 0.03, 0.00 User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.404 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RP_MATCHES_RCVD=-0.504 X-Spam-Level: X-Archive-Number: 201109/175 X-Sequence-Number: 44951 --lbYR4+J2RcKO0WXU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline * Robert Schnabel (schnabelr@missouri.edu) wrote: > And getting back to the to-do list entry and reading the related > posts, it appears that even if you could set work_mem that high it > would only use 2GB anyway. I guess that was the second part of my > question. Is that true? Yes and no. work_mem is used by the planner to figure out what kind of plan to use. The planner plans things based off of statistics, but it's not perfect, especially on large tables with lots of data which have dependent data between columns. Where the 2GB limit comes into play is when you end up with a plan that does, say, a large sort. PG will use memory for the sort up to work_mem, or 2GB, whichever is lower, and spill to disk after that. I don't believe it has such a limit for a hash table, due to how the data structures for the hash table are allocated (and I recall seeing single PG queries that use hash tables getting into the 30+GB range, of course, I had work_mem set upwards of 100GB on a 32GB box... :). So, if you're doing data warehousing, and you're pretty much the only user (or there's only one at a time), setting it up pretty high is acceptable, but you do need to watch the box and make sure you don't run it out of memory. Also, make sure you have things configured correctly, if you're using Linux, to prevent the OOM killer from kicking in. Also, as I suggested before, set it to a reasonable level for the 'default' and just up it for specific queries that may benefit from it. Thanks, Stephen --lbYR4+J2RcKO0WXU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk5urjcACgkQrzgMPqB3kijfhACcDg4jTjcEo1gAIllokXxg2mp2 oOEAnjUJlwCZul7hNqRnms81fKGRiMgo =Kcxn -----END PGP SIGNATURE----- --lbYR4+J2RcKO0WXU--