X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 49CCFDA294 for ; Wed, 5 Oct 2005 16:54:48 -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 93239-06 for ; Wed, 5 Oct 2005 19:54:43 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by svr1.postgresql.org (Postfix) with ESMTP id C6ACDDA2AB for ; Wed, 5 Oct 2005 16:54:41 -0300 (ADT) Received: by rproxy.gmail.com with SMTP id 34so9589rns for ; Wed, 05 Oct 2005 12:54:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WM7PFPf1dqTBf2+255gFh3ckvmNWaYid4ONSPUzCYTakBwOn78KoiAcHvHlfrXopYeFZg133+jGWzXCunNMfCjL+fIRaNwU7e7wj4vgruUAXUv7FJykT82qa71BV3gssVO7i3TG12bqKqbiKOuOFHMcw6IiJCMHZKIQkmI/cY3s= Received: by 10.11.119.14 with SMTP id r14mr9334cwc; Wed, 05 Oct 2005 12:54:42 -0700 (PDT) Received: by 10.11.119.38 with HTTP; Wed, 5 Oct 2005 12:54:42 -0700 (PDT) Message-ID: <36e682920510051254v794908a0o@mail.gmail.com> Date: Wed, 5 Oct 2005 15:54:42 -0400 From: "Jonah H. Harris" Reply-To: "Jonah H. Harris" To: Ron Peacetree Subject: Re: [PERFORM] A Better External Sort? Cc: jd@commandprompt.com, pgsql-hackers@postgresql.org, pgsql-performance@postgresql.org In-Reply-To: <25154967.1128532864650.JavaMail.root@elwamui-chisos.atl.sa.earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <25154967.1128532864650.JavaMail.root@elwamui-chisos.atl.sa.earthlink.net> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.196 required=5 tests=[AWL=0.172, RCVD_BY_IP=0.024] X-Spam-Level: X-Archive-Number: 200510/240 X-Sequence-Number: 74099 Ron, This thread is getting on my nerves. Your tone in some of the other posts (as-well-as this one) is getting very annoying. Yes, PostgreSQL's storage manager (like all other open source databases), lacks many of the characteristics and enhancements of the commercial databases. Unlike Oracle, Microsoft, etc., the PostgreSQL Global Development Group doesn't have the tens of millions of dollars required to pay hundreds of developers around the world for round-the-clock development and R&D. Making sure that every little tweak, on every system, is taken advantage of is expensive (in terms of time) for an open source project where little ROI is gained.=20 Before you make a statement like, "I wanted to verify that pg's IO rates were inferior to The Competition", think about how you'd write your own RDBMS from scratch (in reality, not in theory). As for your question regarding developer docs for the storage manager and related components, read the READMEs and the code... just like everyone else. Rather than posting more assumptions and theory, please read through the code and come back with actual suggestions. -Jonah 2005/10/5, Ron Peacetree : > First I wanted to verify that pg's IO rates were inferior to The Competit= ion. > Now there's at least an indication that someone else has solved similar > problems. Existence proofs make some things easier ;-) > > Is there any detailed programmer level architectual doc set for pg? I kn= ow > "the best doc is the code", but the code in isolation is often the Slow P= ath to > understanding with systems as complex as a DBMS IO layer. > > Ron > > > -----Original Message----- > From: "Joshua D. Drake" > Sent: Oct 5, 2005 1:18 PM > Subject: Re: [HACKERS] [PERFORM] A Better External Sort? > > > The source is freely available for your perusal. Please feel free to > point us in specific directions in the code where you may see some > benefit. I am positive all of us that can, would put resources into > fixing the issue had we a specific direction to attack. > > Sincerely, > > Joshua D. Drake > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match > -- Respectfully, Jonah H. Harris, Database Internals Architect EnterpriseDB Corporation http://www.enterprisedb.com/