Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 012DF632F3C for ; Wed, 23 Dec 2009 13:45:46 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 29176-05 for ; Wed, 23 Dec 2009 17:45:32 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp-out113.alice.it (smtp-out113.alice.it [85.37.17.113]) by mail.postgresql.org (Postfix) with ESMTP id D48ED630F31 for ; Wed, 23 Dec 2009 13:45:33 -0400 (AST) Received: from fbcmmo06.fbc.local ([192.168.184.137]) by smtp-out113.alice.it with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Dec 2009 18:45:31 +0100 Received: from FBCMCL01B08.fbc.local ([192.168.171.46]) by fbcmmo06.fbc.local with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Dec 2009 18:43:19 +0100 Received: from lan.webthatworks.it ([79.0.145.79]) by FBCMCL01B08.fbc.local with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Dec 2009 18:43:19 +0100 Received: from dawn.webthatworks.it (dawn.webthatworks.it [192.168.1.12]) by lan.webthatworks.it (Postfix) with ESMTP id 6F67430056A for ; Wed, 23 Dec 2009 18:43:18 +0100 (CET) Received: from dawn.webthatworks.it (localhost [127.0.0.1]) by dawn.webthatworks.it (Postfix) with ESMTP id 415903DA93 for ; Wed, 23 Dec 2009 18:43:18 +0100 (CET) Date: Wed, 23 Dec 2009 18:43:18 +0100 From: Ivan Sergio Borgonovo To: pgsql-sql@postgresql.org Subject: Re: short-cutting if sum()>constant Message-ID: <20091223184318.5fe9b4d8@dawn.webthatworks.it> In-Reply-To: <28619.1261586191@sss.pgh.pa.us> References: <20091222133527.3007bd96@dawn.webthatworks.it> <162867790912221147r7e3041fej44332a05faf915d6@mail.gmail.com> <20091223000031.54ad09b5@dawn.webthatworks.it> <20091223010940.51c5c069@dawn.webthatworks.it> <20091223024635.48d66554@dawn.webthatworks.it> <162867790912222338v73261b73u5c4e88a5ce85918f@mail.gmail.com> <20091223115628.1709caf5@dawn.webthatworks.it> <162867790912230352v5b6e395fm1880111c04eaa626@mail.gmail.com> <4B323F21.3020007@postnewspapers.com.au> <28619.1261586191@sss.pgh.pa.us> Organization: http://www.webthatworks.it X-Mailer: Claws Mail 3.7.3 (GTK+ 2.18.5; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Dec 2009 17:43:19.0186 (UTC) FILETIME=[69FD7720:01CA83F7] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.321 tagged_above=-10 required=5 tests=AWL=0.278, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 200912/80 X-Sequence-Number: 33518 On Wed, 23 Dec 2009 11:36:31 -0500 Tom Lane wrote: > Craig Ringer writes: > > Pavel Stehule wrote: > >> these queries are executed in some special mode, but still it > >> is more expensive than C a = a + 1 > > > ... and may have different rules, so you can't just write a > > simple "map expressions to C equivalents" arithmetic evaluator. > Yeah. As an example, overflow is supposed to be caught in "a + 1", > unlike what would happen in C. > In principle you could map some of the builtin operators into > inline code, but it would be a great deal of work and the results > would be un-portable. Tank you all for being so patient... I really miss how actually procedural languages works internally. doesn't pg routinely map between SQL and C? What is the difference between select a+a from data; and a := a + a; in a plpgsql function? plpgsql knows that a are eg. int so it could just use the same C code that it uses when it has to sum a+a in sql. My guess since I don't even know what to look for to get an idea of the internal working of plpgsql is that the interpreter translate the code into SQL (sort of...), it sends it to the parser through SPI_execute/prepare etc... (so yeah maybe for the "data" it is not really sending "text" representation of data) but still... the "code" has to be further interpreted... So something like: a := a + a; turns out to be: SPI_prepare("SELECT $1 + $2", 2, ...); and this is going to be called for every loop. while I thought the SQL engine and plpgsql interpreter were nearer so that the interpreter could push directly in the SQL engine the values of a. Am I getting nearer? -- Ivan Sergio Borgonovo http://www.webthatworks.it