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 4B856D71FA for ; Wed, 24 Aug 2005 07:35:12 -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 87077-08 for ; Wed, 24 Aug 2005 10:35:09 +0000 (GMT) Received: from boutiquenumerique.com (boutiquenumerique.com [82.67.9.10]) by svr1.postgresql.org (Postfix) with ESMTP id 7CACFD7164 for ; Wed, 24 Aug 2005 07:35:07 -0300 (ADT) Received: (qmail 7628 invoked from network); 24 Aug 2005 12:35:33 +0200 Received: from unknown (HELO localhost) (boutiquenumerique-lists@192.168.0.4) by boutiquenumerique.com with SMTP; 24 Aug 2005 12:35:33 +0200 Date: Wed, 24 Aug 2005 12:35:08 +0200 To: "Tom Lane" , "Jeffrey W. Baker" Subject: Re: Read/Write block sizes Cc: "Guy Thornley" , "Josh Berkus" , pgsql-performance@postgresql.org, "Steve Poe" , "Chris Browne" References: <60k6icpapm.fsf@dba2.int.libertyrms.com> <1124846743.12045.94.camel@amd64-laptop-spoe> <200508231931.29682.josh@agliodbs.com> <1124852854.11147.5.camel@noodles> <20050824052023.GB31806@conker.esphion.com> <1124861121.11270.1.camel@noodles> <21700.1124863004@sss.pgh.pa.us> From: PFC Organization: =?iso-8859-15?Q?La_Boutique_Num=E9rique?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <21700.1124863004@sss.pgh.pa.us> User-Agent: Opera M2/8.0 (Linux, build 1095) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.005 required=5 tests=[AWL=0.005] X-Spam-Level: X-Archive-Number: 200508/379 X-Sequence-Number: 14126 > of effort reinventing the wheel ... but our time will be repaid much > more if we work at levels that the OS cannot have knowledge of, such as > join planning and data statistics. Considering a global budget of man-hours which is the best ? 1- Spend it on reimplementing half of VFS in postgres, half of Windows in postgres, half of FreeBSD in postgres, half of Solaris in Postgres, only to discover you gain a meagre speed increase and a million and a half bugs, 2- Spending 5% of that time lowering the impedance between the OS and Postgres, and another 5% annoying Kernel people and helping them tweaking stuff for database use, and the rest on useful features that give useful speedups, like bitmap indexes, skip scans, and other features that enhance power and usability ? If you're Oracle and have almost unlimited resources, maybe. But even Microsoft opted for option 2 : they implemented ReadFileGather and WriteFileScatter to lower the syscall overhead and that's it. And point 2 will benefit to many other apps, wether 1 would benefit only postgres, and then only in certain cases. I do believe there is something ineresting to uncover with reiser4 though (it definitely fits point 2). I'm happy that the pg team chose point 2 and that new versions keep coming with new features at an unbelievable rate these times. Do you guys sleep ?