Received: from localhost (maia-3.hub.org [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 3C7C89FB1E6 for ; Tue, 3 Apr 2007 18:40:58 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 94620-01 for ; Tue, 3 Apr 2007 18:40:50 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from 66-226-76-106.dedicated.abac.net (66-226-76-106.dedicated.abac.net [66.226.76.106]) by postgresql.org (Postfix) with ESMTP id 8059A9FB95C for ; Tue, 3 Apr 2007 18:40:53 -0300 (ADT) Received: (qmail 7942 invoked by uid 2020); 3 Apr 2007 14:40:51 -0700 Received: from wsip-70-167-125-69.sd.sd.cox.net (HELO ?192.168.0.3?) (70.167.125.69) by 192.168.0.4 with (DHE-RSA-AES256-SHA encrypted) SMTP; 3 Apr 2007 14:40:51 -0700 Message-ID: <4612CB72.6010804@modgraph-usa.com> Date: Tue, 03 Apr 2007 14:47:30 -0700 From: "Craig A. James" User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Kevin Grittner CC: pgsql-performance@postgresql.org Subject: Re: [HACKERS] EXISTS optimization References: <4603C1A3.EE98.0025.0@wicourts.gov> <25339.1174686582@sss.pgh.pa.us> <46040DAC.EE98.0025.0@wicourts.gov> <46044683.EE98.0025.0@wicourts.gov> In-Reply-To: <46044683.EE98.0025.0@wicourts.gov> 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=2.562 tagged_above=0 required=5 tests=AWL=-1.257, BAYES_50=0.001, HELO_DYNAMIC_IPADDR2=3.818 X-Spam-Level: ** X-Archive-Number: 200704/40 X-Sequence-Number: 23917 Kevin Grittner wrote: > Management has simply given a mandate that the software be independent > of OS and database vendor, and to use Java to help with the OS independence. > ... we write all of our queries in ANSI SQL in our own query tool, parse it, > and generate Java classes to run it. A better solution, and one I've used for years, is to use OS- or database-specific features, but carefully encapsulate them in a single module, for example, "database_specific.java". For example, when I started supporting both Oracle and Postgres, I encountered the MAX() problem, which (at the time) was very slow in Postgres, but could be replaced by "select X from MYTABLE order by X desc limit 1". So I created a function, "GetColumnMax()" that encapsulates the database-specific code for this. Similar functions encapsulate and a number of other database-specific optimizations. Another excellent example: I have a function called "TableExists(name)". To the best of my knowledge, there simply is no ANSI SQL for this, so what do you do? Encapsulate it in one place. The result? When I port to a new system, I know exactly where to find all of the non-ANSI SQL. I started this habit years ago with C/C++ code, which has the same problem: System calls are not consistent across the varients of Unix, Windows, and other OS's. So you put them all in one file called "machine_dependent.c". Remember the old adage: There is no such thing as portable code, only code that has been ported. Cheers, Craig