X-Original-To: pgsql-sql-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id B611B9FA5D2 for ; Thu, 15 Jun 2006 19:19:47 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 59384-04 for ; Thu, 15 Jun 2006 19:19:42 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey- Received: from web33315.mail.mud.yahoo.com (web33315.mail.mud.yahoo.com [68.142.206.130]) by postgresql.org (Postfix) with SMTP id 6C8449FA160 for ; Thu, 15 Jun 2006 19:19:42 -0300 (ADT) Received: (qmail 38144 invoked by uid 60001); 15 Jun 2006 22:19:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ej7kLSA6ZRgAvzUGtF0i0PTMVUwsswg8E/535tkx4qXyw3K2HTlsLSywR+qyv11Cbi4DZmL+M1Qc8qcxoKimZrLMKbrGAV1uUqgcv9k6NNwyO1YtNJ/WeSIc8Qj3RUR3k/0jf+iLrJ9swNT0jnpYqlPdsr430YMu3UAQhGb+Xo8= ; Message-ID: <20060615221940.38142.qmail@web33315.mail.mud.yahoo.com> Received: from [12.9.179.126] by web33315.mail.mud.yahoo.com via HTTP; Thu, 15 Jun 2006 15:19:40 PDT Date: Thu, 15 Jun 2006 15:19:40 -0700 (PDT) From: Subject: Re: SQL Technique Question To: Andrew Sullivan , pgsql-sql@postgresql.org In-Reply-To: <20060615210322.GA22035@phlogiston.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/189 X-Sequence-Number: 25425 > On Thu, Jun 15, 2006 at 01:59:22PM -0700, > operationsengineer1@yahoo.com wrote: > > > > is it a good practice to leave this included in > the > > queries, as is, or should i factor it out somehow? > if > > i should factor it, how do i do so? > > If what you're saying is that these additional > criteria are > redundant, then it's up to you: what do you want to > optimise for? If > you're protecting against future errors, then the > additional > criteria might help. If you're protecting against > having to write > your code to produce a more efficient query, you > should weigh the > cost and benefit (which benefit includes "easier to > debug queries"). > There is a probably non-zero cost to the extra > joins. Andrew and Rod, my apologies for not being more clear in my question. all the code is required to get from t_inspect_result data back to t_product information. however, many of the joins are used over and over and over - making for a complex query to view and try and to debug - not to mention forcing a long trail of chasing linked data to get from t_inspect_result_id back to the linked t_product data. Thanks for taking the time to address the question - and i will try and be more clear going forward. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com