Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 22E3E650489 for ; Tue, 9 Dec 2008 18:38:45 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 83571-03 for ; Tue, 9 Dec 2008 18:38:41 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 1070E650441 for ; Tue, 9 Dec 2008 18:38:40 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id mB9Mca9G022286; Tue, 9 Dec 2008 17:38:36 -0500 (EST) To: Scott Carey cc: "jd@commandprompt.com" , Merlin Moncure , Scott Marlowe , Jean-David Beyer , "pgsql-performance@postgresql.org" Subject: Re: Need help with 8.4 Performance Testing In-reply-to: References: Comments: In-reply-to Scott Carey message dated "Tue, 09 Dec 2008 14:05:18 -0800" Date: Tue, 09 Dec 2008 17:38:35 -0500 Message-ID: <22285.1228862315@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200812/93 X-Sequence-Number: 32129 Scott Carey writes: > Which brings this back around to the point I care the most about: > I/O per second will diminish as the most common database performance limiting factor in Postgres 8.4's lifetime, and become almost irrelevant in 8.5's. > Becoming more CPU efficient will become very important, and for some, already is. The community needs to be proactive on this front. > This turns a lot of old assumptions on their head, from the database down through the OS and filesystem. We're bound to run into many surprises due to this major shift in something that has had its performance characteristics taken for granted for decades. Hmm ... I wonder whether this means that the current work on parallelizing I/O (the posix_fadvise patch in particular) is a dead end. Because what that is basically going to do is expend more CPU to improve I/O efficiency. If you believe this thesis then that's not the road we want to go down. regards, tom lane