Return-Path: X-Original-To: apmail-db-derby-user-archive@www.apache.org Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3BA7B77D9 for ; Wed, 21 Dec 2011 11:59:31 +0000 (UTC) Received: (qmail 7302 invoked by uid 500); 21 Dec 2011 11:59:30 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 7243 invoked by uid 500); 21 Dec 2011 11:59:30 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 7236 invoked by uid 99); 21 Dec 2011 11:59:30 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Dec 2011 11:59:30 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates 216.139.236.26 as permitted sender) Received: from [216.139.236.26] (HELO sam.nabble.com) (216.139.236.26) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Dec 2011 11:59:25 +0000 Received: from isper.nabble.com ([192.168.236.156]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1RdKp6-00072U-Ls for derby-user@db.apache.org; Wed, 21 Dec 2011 03:59:04 -0800 Message-ID: <33016245.post@talk.nabble.com> Date: Wed, 21 Dec 2011 03:59:04 -0800 (PST) From: JulioSerje To: derby-user@db.apache.org Subject: Re: UPDATE FROM JOIN In-Reply-To: <4EEFA2FA.2090801@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jserje@gmail.com References: <32989399.post@talk.nabble.com> <4EEF43E1.7010409@oracle.com> <33005383.post@talk.nabble.com> <4EEFA2FA.2090801@oracle.com> Hi Rick, Unfortunately our expressions would require a high number of subqueries; ours is an engineering application that require many values from several tables in order to compute multiple complex formulae. In our specific case we know that by design that our UPDATE ..FROM statements will compute the same as the statement based on subqueries (i.e. statements are not ambiguous at all). The question is, are you aware of any plans to implement MERGE in Derby? In the meanwhile we are considering the use of an intermediate table with results INSERTed, as insert can use a full fledged select clause, and later use a much simpler UPDATE statement with less and simpler subqueries. Thanks again, Julio Are there any plans to Rick Hillegas-3 wrote: > > Hi Julio, > > I haven't looked into the details of what the Derby optimizer does in > the case of multiple SET clauses, each driven by its own subselect. It > is likely that this is an underoptimized case. If you rewrite your query > to use subselects in the SET clauses, and you experience poor > performance on Derby, you may be able to get advice on this list about > how to improve that performance. > > It is possible that the Derby UDPATE will compute different results than > the UPDATE...FROM statements in your other databases. Derby may even > raise an error. If Derby raises an error, this may be a warning to you > that your UPDATE...FROM statements are ambiguous. An UPDATE...FROM > statement may end up updating the same column multiple times in a > non-deterministic way. This can happen if the join in the FROM clause > returns multiple joined rows for each row in the table you are updating. > In this situation, the standard syntax will raise an error because the > subselects are supposed to return one row each. More information on this > problem can be found here: > http://sqlblog.com/blogs/hugo_kornelis/archive/2008/03/10/lets-deprecate-update-from.aspx > > Hope this is helpful, > -Rick > > -- View this message in context: http://old.nabble.com/UPDATE-FROM-JOIN-tp32989399p33016245.html Sent from the Apache Derby Users mailing list archive at Nabble.com.