X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 8BA8D9F9A8D for ; Mon, 22 May 2006 12:15:02 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 45755-09 for ; Mon, 22 May 2006 12:14:52 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from exchange.g2switchworks.com (mail.g2switchworks.com [63.87.162.25]) by postgresql.org (Postfix) with ESMTP id AF68B9F9316 for ; Mon, 22 May 2006 12:14:52 -0300 (ADT) Received: from 10.10.1.37 ([10.10.1.37]) by exchange.g2switchworks.com ([10.10.1.2]) with Microsoft Exchange Server HTTP-DAV ; Mon, 22 May 2006 15:14:51 +0000 Received: from state.g2switchworks.com by mail.g2switchworks.com; 22 May 2006 10:14:51 -0500 Subject: Re: utilizing multiple disks for i/o performance From: Scott Marlowe To: Kenji Morishige Cc: pgsql-performance@postgresql.org In-Reply-To: <20060520023745.GA14877@juniper.net> References: <20060520023745.GA14877@juniper.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1148310891.30414.54.camel@state.g2switchworks.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 22 May 2006 10:14:51 -0500 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/415 X-Sequence-Number: 19202 On Fri, 2006-05-19 at 21:37, Kenji Morishige wrote: > Where can I find any documentation to partition the tablespace disk files onto > different physical arrays for improved performance? There have been quite a few posts to this list in the past about this, so searching it might be a good start. Firstly, you need to defined "improved performance". Are we talking transactional throughput (OLTP), or batch updates (ETL), or report generation (OLAP stuff)??? Or some other scenario. For write performance, the general rules are: You can only commit 1 transaction per rotation of a properly fsynced disc that holds the WAL file (i.e. the pg_xlog directory). So, putting that on it's own fast spinning disc is step one for improved performance. A battery backed cache unit (BBU) on a RAID controller is a must. RAID 1+0 is a good choice for your data partition. For many hardware RAID controllers with the above mentioned BBU moving the pg_xlog to another partition is no real help. Cheap RAID controllers are often worse than no RAID controller. If you can't afford a good RAID controller, you're probably better off with software RAID than using a cheapie. For READ performance: Often settings in postgresql.conf are far more important than the drive layout. Lots of RAM is a good thing. Assuming you've got lots of RAM, making shared_buffers anywhere from 10 to 25% of it is a pretty good size. work_mem usually works well at around 16 meg or so. drop random_page_cost to about 2 for most systems. Lastly, read this: http://www.varlena.com/GeneralBits/Tidbits/perf.html