Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 3608F101438F for ; Thu, 1 Mar 2012 19:08:50 -0400 (AST) Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1S3F7A-0005ez-J6 for pgsql-performance@postgresql.org; Thu, 01 Mar 2012 23:08:49 +0000 X-Originating-IP: 217.70.178.141 Received: from mfilter13-d.gandi.net (mfilter13-d.gandi.net [217.70.178.141]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 329D917208F; Fri, 2 Mar 2012 00:08:24 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter13-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter13-d.gandi.net (mfilter13-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id rPvV2d6Ud+Y5; Fri, 2 Mar 2012 00:08:22 +0100 (CET) X-Originating-IP: 98.27.54.176 Received: from [192.168.10.146] (cpe-098-027-054-176.nc.res.rr.com [98.27.54.176]) (Authenticated sender: adsend@dunslane.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id E569B172067; Fri, 2 Mar 2012 00:08:20 +0100 (CET) Message-ID: <4F500163.9090200@dunslane.net> Date: Thu, 01 Mar 2012 18:08:19 -0500 From: Andrew Dunstan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: Stefan Keller CC: Jeff Janes , Claudio Freire , postgres performance list Subject: Re: PG as in-memory db? How to warm up and re-populate buffers? How to read in all tuples into memory? References: <4F4A4DD6.6090904@squeakycode.net> <4F4A861A.3000301@squeakycode.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201203/33 X-Sequence-Number: 46483 On 03/01/2012 05:52 PM, Stefan Keller wrote: > These are the current modified settings in postgresql.conf: > shared_buffers = 128MB > work_mem = 3MB These are extremely low settings on virtually any modern computer. I usually look to set shared buffers in numbers of Gb and work_mem at least in tens if not hundreds of Mb for any significantly sized database. cheers andrew