X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id B4A039DCA3C for ; Fri, 17 Mar 2006 16:03:41 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 83334-10 for ; Fri, 17 Mar 2006 16:03:41 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.Mi8.com (d01gw01.mi8.com [63.240.6.47]) by postgresql.org (Postfix) with ESMTP id 33FD19DCA4A for ; Fri, 17 Mar 2006 16:03:38 -0400 (AST) Received: from 172.16.1.112 by mail.Mi8.com with ESMTP (- Welcome to Mi8 Corporation www.Mi8.com (D1)); Fri, 17 Mar 2006 15:03:29 -0500 X-Server-Uuid: 241911D6-425B-44B9-A073-E3FE0F8FC774 Received: from MI8NYCMAIL06.Mi8.com ([172.16.1.160]) by D01SMTP02.Mi8.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Mar 2006 15:03:23 -0500 Received: from 208.54.95.129 ([208.54.95.129]) by MI8NYCMAIL06.Mi8.com ( [172.16.1.219]) via Exchange Front-End Server mi8owa.mi8.com ( [172.16.1.106]) with Microsoft Exchange Server HTTP-DAV ; Fri, 17 Mar 2006 20:03:24 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 17 Mar 2006 15:03:19 -0800 Subject: Re: 1 TB of memory From: "Luke Lonergan" To: "Jim C. Nasby" cc: pgsql-performance@postgresql.org Message-ID: Thread-Topic: [PERFORM] 1 TB of memory Thread-Index: AcZJ6WwgHyJ1TlwcSCKu7QUg2reFXAALY8EE In-Reply-To: <20060317173653.GC15742@pervasive.com> MIME-Version: 1.0 X-OriginalArrivalTime: 17 Mar 2006 20:03:23.0901 (UTC) FILETIME=[D8C572D0:01C649FD] X-WSS-ID: 6805C9853XK326766-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=2.489 required=5 tests=[RCVD_IN_SORBS_WEB=1.236, RCVD_NUMERIC_HELO=1.253] X-Spam-Score: 2.489 X-Spam-Level: ** X-Archive-Number: 200603/287 X-Sequence-Number: 17724 Jim, On 3/17/06 9:36 AM, "Jim C. Nasby" wrote: > Now what happens as soon as you start doing random I/O? :) Well - given that we've divided the data into 32 separate segments, and that seeking is done in parallel over all 256 disk drives, random I/O rocks hard and scales. Of course, the parallelizing planner is designed to minimize seeking as much as possible, as is the normal Postgres planner, but with more segment and more parallel platters, seeking is faster. The biggest problem with this idea of "put huge amounts of data on your SSD and everything is infinitely fast" is that it ignores several critical scaling factors: - How much bandwidth is available in and out of the device? - Does that bandwidth scale as you grow the data? - As you grow the data, how long does it take to use the data? - Can more than 1 CPU use the data at once? Do they share the path to the data? If you are accessing 3 rows at a time from among billions, the problem you have is mostly access time - so an SSD might be very good for some OLTP applications. However - the idea of putting Terabytes of data into an SSD through a thin straw of a channel is silly. Note that SSDs have been around for a *long* time. I was using them on Cray X/MP and 2 supercomputers back in 1987-92, when we had a 4 Million Word SSD connected over a 2GB/s channel. In fact, some people I worked with built a machine with 4 Cray 2 computers that shared an SSD between them for parallel computing and it was very effective, and also ungodly expensive and special purpose. - Luke