Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1abBw5-0007iA-Is for pgsql-performance@arkaria.postgresql.org; Wed, 02 Mar 2016 18:55:49 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1abBw5-0003HY-3J for pgsql-performance@arkaria.postgresql.org; Wed, 02 Mar 2016 18:55:49 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1abBuP-0000qu-UD for pgsql-performance@postgresql.org; Wed, 02 Mar 2016 18:54:05 +0000 Received: from evolu-s.it ([94.23.66.144] helo=smtp.evolu-s.it) by magus.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1abBuN-00057i-EP for pgsql-performance@postgresql.org; Wed, 02 Mar 2016 18:54:05 +0000 Received: from [192.168.1.100] ([93.62.73.47]) by smtp.evolu-s.it ; Wed, 2 Mar 2016 19:54:03 +0100 Subject: Re: [SPAM] Re: autovacuum disk IO To: pgsql-performance@postgresql.org References: <20160302184026.GA436128@alvherre.pgsql> From: Moreno Andreo Message-ID: <56D736CF.2010908@evolu-s.it> Date: Wed, 2 Mar 2016 19:54:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160302184026.GA436128@alvherre.pgsql> Content-Type: text/plain; charset=windows-1252; 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 Il 02/03/2016 19:40, Alvaro Herrera ha scritto: > Scott Marlowe wrote: >> On Wed, Mar 2, 2016 at 9:11 AM, Moreno Andreo wrote: >>> ... or maybe add some more RAM to have more disk caching (if you're on >>> *nix).... this worked for me in the past... even if IMHO it's more a >>> temporary "patch" while upgrading (if it can't be done in a hurry) than a >>> real solution... >> Oh yeah, definitely worth looking at. But RAM can't speed up writes, >> just reads, so it's very workload dependent. If you're IO subsystem is >> maxing out on writes, faster drives / IO. If it's maxing out on reads, >> more memory. But if your dataset is much bigger than memory (say 64GB >> RAM and a 1TB data store) then more RAM isn't going to be the answer. > In the particular case of autovacuum, it may be helpful to create a > "ramdisk" and put the stats temp file in it. > Definitely. I my new server (as I've been taught here :-) ) I'm going to put stats in a ramdisk and pg_xlog in another partition. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance