Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id EA892650162 for ; Tue, 9 Dec 2008 21:37: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 16788-06 for ; Tue, 9 Dec 2008 21:37:43 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp108.biz.mail.mud.yahoo.com (smtp108.biz.mail.mud.yahoo.com [68.142.201.177]) by mail.postgresql.org (Postfix) with SMTP id 0791964FCED for ; Tue, 9 Dec 2008 21:37:42 -0400 (AST) Received: (qmail 72427 invoked from network); 10 Dec 2008 01:37:40 -0000 Received: from unknown (HELO ?192.168.5.110?) (rm_pg@76.202.61.102 with plain) by smtp108.biz.mail.mud.yahoo.com with SMTP; 10 Dec 2008 01:37:40 -0000 X-YMail-OSG: 1vb7nzMVM1kaI6.AApWXFfqOHyEK8YDOkpd414DEo9NSp1O_7VjnmBpE.2FTtxNU68sQ3kCO_HUMzww1FBCIuDuGsp0XFXNJyZT5PINMwb9M506wvAbv1HAHbKkCaQSm7x.LpeRmpevjlf1Qt6DZxaLydw6DW2YuNBKSH61uh1VlfeylXajS2LV.U1zW X-Yahoo-Newman-Property: ymail-3 Message-ID: <493F1D65.80300@cheapcomplexdevices.com> Date: Tue, 09 Dec 2008 17:37:41 -0800 From: Ron Mayer User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Tom Lane CC: Scott Carey , "jd@commandprompt.com" , Merlin Moncure , Scott Marlowe , Jean-David Beyer , "pgsql-performance@postgresql.org" Subject: Re: Need help with 8.4 Performance Testing References: <22285.1228862315@sss.pgh.pa.us> In-Reply-To: <22285.1228862315@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/103 X-Sequence-Number: 32139 Tom Lane wrote: > 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. > I imagine the larger postgres installations will still benefit from this patch - because I imagine they will stay on hard disks for quite some time; simply because the cost of 70TB of disks seems like it'll be lower than RAM for at least the intermediate term. I imagine the smaller postgres installations will also still benefit from this patch - because my postgres installations with the most painful I/O bottlenecks are small virtual machines without dedicated drives where I/O (I guess emulated by the virtual machine software) is very painful. Perhaps there's a mid-sized system that won't benefit from fadvise() in the intermediate term -- where the size of the database is about the same size as a cost-effective flash drive -- but I don't have any databases in that range now.