X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 0DC7ED9238; Fri, 23 Sep 2005 11:09:44 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 75218-05; Fri, 23 Sep 2005 14:09:39 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id BAE20D9253; Fri, 23 Sep 2005 11:09:41 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j8NE9eRf003466; Fri, 23 Sep 2005 10:09:40 -0400 (EDT) To: Simon Riggs Cc: pgsql-hackers@postgresql.org, pgsql-performance@postgresql.org Subject: Re: Releasing memory during External sorting? In-reply-to: <1127468233.4145.178.camel@localhost.localdomain> References: <1127468233.4145.178.camel@localhost.localdomain> Comments: In-reply-to Simon Riggs message dated "Fri, 23 Sep 2005 10:37:12 +0100" Date: Fri, 23 Sep 2005 10:09:39 -0400 Message-ID: <3465.1127484579@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.006 required=5 tests=[AWL=0.006] X-Spam-Level: X-Archive-Number: 200509/1005 X-Sequence-Number: 73402 Simon Riggs writes: > If not, I would propose that when we move from qsort to tapesort mode we > free the larger work_mem setting (if one exists) and allocate only a > lower, though still optimal setting for the tapesort. That way the > memory can be freed for use by other users or the OS while the tapesort > proceeds (which is usually quite a while...). On most platforms it's quite unlikely that any memory would actually get released back to the OS before transaction end, because the memory blocks belonging to the tuplesort context will be intermixed with blocks belonging to other contexts. So I think this is pretty pointless. (If you can't afford to have the sort using all of sort_mem, you've set sort_mem too large, anyway.) regards, tom lane