Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vu0ms-0007og-Ii for pgsql-performance@arkaria.postgresql.org; Fri, 20 Dec 2013 14:10:46 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Vu0mr-0001uL-Ub for pgsql-performance@arkaria.postgresql.org; Fri, 20 Dec 2013 14:10:45 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vu0mq-0001uE-Md for pgsql-performance@postgresql.org; Fri, 20 Dec 2013 14:10:44 +0000 Received: from smtp.peak6.com ([38.98.137.6]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vu0mh-0006FN-1K for pgsql-performance@postgresql.org; Fri, 20 Dec 2013 14:10:44 +0000 X-AuditID: 0a64cb20-b7f256d000000fb3-62-52b44fd80eb9 Message-ID: <52B44FD8.2030105@optionshouse.com> Date: Fri, 20 Dec 2013 08:10:32 -0600 From: Shaun Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Dave Johansen CC: pgsql-performance Subject: Re: Unexpected pgbench result References: <52B33069.1060203@optionshouse.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed content-transfer-encoding: 7bit X-Originating-IP: [10.10.201.64] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsXClcIroXvDf0uQwcOZhhb/2/4wWlyfeY7Z gclj56y77B4X9k1jD2CKamC0SczLyy9JLElVSEktTrZV8i8oyczPK/bILy1OVXDJLE7OSczM TS1SUshMsVUyVlIoyElMTs1NzSuxVUosKEjNS1Gy41LAADZAZZl5Cql5yfkpmXnptkqewf66 FhamlrqGSnbxyCChkyVj3pED7AXb2St+7O9haWD8w9rFyMkhIWAisWztPGYIW0ziwr31bCA2 r4C+xNKHG5lAbBYBVYkfpxeD1bMJ6EpM6l8BViMqECbRfmEmM0S9oMTJmU9Yuhg5OEQEtCQ+ rXMACTMLWEhsb9/CDmILCxhILLl4BaiVi0NIYCejxPwVL8FmcgoESpz62MwM0WArcWHOdRYI W15i+9s5YHEhoBtWNE9kg7hTQeL/lXdMExgFZiFZPQtJ+ywk7QsYmVcxiheXJSZnZJoWFOeW FBjpFaQmZpvp5aWWbGIER+JphR2M3zutDjEKcDAq8fAqmGwOEmJNLCuuzD3EKMHBrCTC+9ln S5AQb0piZVVqUX58UWlOavEhRh9g2ExklhJNzgcmibySeENjUwNTS1NDU3NTQyMcwkrivFw5 U4OEBNKBqSE7NbUgtQhmHBMHp1QDo4palqmtaNNntvh3a7qszzyIXjlZSXCHT9m0yze+ftgh 3LHosPVBJztzFrbVvEu+GP/YeHj6Lp/iW5v2VnvJmSkasLpMnRVa8Nxkb8PKa8aHDzM+ltOY aTlb4lzLXd+YXSLO9Ykqm942mD84HBxwii+EfWd24uHti2oeyeY81GheXy+z+SnbYyWW4oxE Qy3mouJEAIQIStnxAgAA 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 12/19/2013 04:06 PM, Dave Johansen wrote: > Right now, we're running a RAID 1 for pg_clog, pg_log and pg_xlog and > then a RAID 1+0 with 12 disks for the data. Would there be any benefit > to running a separate RAID 1+0 with a tablespace for the indexes? Not really. PostgreSQL doesn't currently support parallel backend fetches, aggregation, or really anything. It's looking like 9.4 will get us a lot closer to that, but right now, everything is serial. Serial or not, separate backends will have separate read concerns, and PostgreSQL 9.2 and above *do* support index only scans. So theoretically, you might actually see some benefit there. If it were me and I had spindles available, I would just increase the overall size of the pool. It's a lot easier than managing multiple tablespaces. -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604 312-676-8870 sthomas@optionshouse.com ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance