Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WZqzS-0008D9-Jv for pgsql-performance@arkaria.postgresql.org; Tue, 15 Apr 2014 00:12:42 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WZqzR-0005rf-Tq for pgsql-performance@arkaria.postgresql.org; Tue, 15 Apr 2014 00:12:41 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WZqzQ-0005rY-QQ for pgsql-performance@postgresql.org; Tue, 15 Apr 2014 00:12:40 +0000 Received: from relay5-d.mail.gandi.net ([2001:4b98:c:538::197]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WZqzN-0004cC-5P for pgsql-performance@postgresql.org; Tue, 15 Apr 2014 00:12:40 +0000 Received: from mfilter5-d.gandi.net (mfilter5-d.gandi.net [217.70.178.132]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 16E4541C056; Tue, 15 Apr 2014 02:12:35 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter5-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter5-d.gandi.net (mfilter5-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id eEKT7vLKhIJo; Tue, 15 Apr 2014 02:12:33 +0200 (CEST) X-Originating-IP: 98.27.58.255 Received: from [192.168.10.146] (cpe-098-027-058-255.nc.res.rr.com [98.27.58.255]) (Authenticated sender: adsend@dunslane.net) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 0DB3A41C05D; Tue, 15 Apr 2014 02:12:32 +0200 (CEST) Message-ID: <534C796F.7040904@dunslane.net> Date: Mon, 14 Apr 2014 20:12:31 -0400 From: Andrew Dunstan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nick Eubank CC: pgsql-performance@postgresql.org Subject: Re: Tuning Postgres for Single connection use References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On 04/14/2014 05:46 PM, Nick Eubank wrote: > > Any rules of thumb for |work_mem|, |maintenance_work_mem|, > |shared_buffer|, etc. for a database that DOESN'T anticipate > concurrent connections and that is doing lots of aggregate functions > on large tables? All the advice I can find online on tuning (this > , this > , > this > etc.) is > written for people anticipating lots of concurrent connections. > > I'm a social scientist looking to use Postgres not as a database to be > shared by multiple users, but rather as my own tool for manipulating a > massive data set (I have 5 billion transaction records (600gb in csv) > and want to pull out unique user pairs, estimate aggregates for > individual users, etc.). This also means almost no writing, except to > creation of new tables based on selections from the main table. > > I'm on a Windows 8 VM with 16gb ram, SCSI VMware HD, and 3 cores if > that's important. > > First up would probably be "don't run on Windows". shared_buffers above 512Mb causes performance to degrade on Windows, while that threshold is much higher on *nix. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance