X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id BAA0AD7712 for ; Thu, 25 Aug 2005 17:49:39 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 93231-01 for ; Thu, 25 Aug 2005 20:49:37 +0000 (GMT) Received: from floppy.pyrenet.fr (floppy.pyrenet.fr [194.116.145.2]) by svr1.postgresql.org (Postfix) with ESMTP id 819F9D76C8 for ; Thu, 25 Aug 2005 17:49:35 -0300 (ADT) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id 2124E31F50; Thu, 25 Aug 2005 23:02:09 +0200 (MET DST) From: Chris Browne X-Newsgroups: pgsql.performance Subject: Re: Read/Write block sizes Date: Thu, 25 Aug 2005 16:49:26 -0400 Organization: cbbrowne Computing Inc Lines: 41 Message-ID: <604q9doi7d.fsf@dba2.int.libertyrms.com> References: <21700.1124863004@sss.pgh.pa.us> <1124864572.11270.16.camel@noodles> <200508251245.03473.josh@agliodbs.com> <6.2.3.4.0.20050825162308.05dbf298@pop.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@news.hub.org User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.17 (Jumbo Shrimp, linux) Cancel-Lock: sha1:ySqOwaJz/b3BL3ibyrYi6KhtleU= To: pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.109 required=5 tests=[AWL=0.109] X-Spam-Level: X-Archive-Number: 200508/425 X-Sequence-Number: 14172 rjpeace@earthlink.net (Ron) writes: > At 03:45 PM 8/25/2005, Josh Berkus wrote: >> > Ask me sometime about my replacement for GNU sort. Â It uses the >> > same sorting algorithm, but it's an order of magnitude faster due >> > to better I/O strategy. Â Someday, in my infinite spare time, I >> > hope to demonstrate that kind of improvement with a patch to pg. >> >>Since we desperately need some improvements in sort performance, I >>do hope you follow up on this. > > I'll generalize that. IMO we desperately need any and all > improvements in IO performance. Even more so than we need > improvements in sorting or sorting IO performance. That's frankly a step backwards. Feel free to "specialise" that instead. A patch that improves some specific aspect of performance is a thousand times better than any sort of "desperate desire for any and all improvements in I/O performance." The latter is unlikely to provide any usable result. The "specialized patch" is also pointedly better in that a *confidently submitted* patch is likely to be way better than any sort of "desperate clutching at whatever may come to hand." Far too often, I see people trying to address performance problems via the "desperate clutching at whatever seems near to hand," and that generally turns out very badly as a particular result of the whole "desperate clutching" part. If you can get a sort improvement submitted, that's a concrete improvement... -- select 'cbbrowne' || '@' || 'ntlug.org'; http://www3.sympatico.ca/cbbrowne/lisp.html Appendium to the Rules of the Evil Overlord #1: "I will not build excessively integrated security-and-HVAC systems. They may be Really Cool, but are far too vulnerable to breakdowns."