X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id EB85E11F691F for ; Thu, 6 Apr 2006 09:45:28 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 45540-03 for ; Thu, 6 Apr 2006 09:45:21 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from smtpout.eastlink.ca (smtpout.eastlink.ca [24.222.0.30]) by postgresql.org (Postfix) with ESMTP id 13E3C11F692F for ; Thu, 6 Apr 2006 09:45:25 -0300 (ADT) Received: from ip01.eastlink.ca ([24.222.10.5]) by mta01.eastlink.ca (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0IXA006WFWRUE3Y1@mta01.eastlink.ca> for pgsql-sql@postgresql.org; Thu, 06 Apr 2006 09:45:30 -0300 (ADT) Received: from blk-224-208-192.eastlink.ca (HELO tickletrunk.engtech.eng) ([24.224.208.192]) by ip01.eastlink.ca with ESMTP; Thu, 06 Apr 2006 09:45:25 -0300 Date: Thu, 06 Apr 2006 09:45:23 -0300 From: Michael Burke Subject: Re: SELECT composite type In-reply-to: <12793.1144276168@sss.pgh.pa.us> To: pgsql-sql@postgresql.org Message-id: <200604060945.24231.michael@engtech.ca> Organization: Engineering Technologies Canada Ltd. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= References: <200604051257.09980.michael@engtech.ca> <40485D0C-8C3A-4206-9825-3A459934F356@tele2.se> <12793.1144276168@sss.pgh.pa.us> User-Agent: KMail/1.9.1 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0 required=5 tests=[none] X-Spam-Score: 0 X-Spam-Level: X-Archive-Number: 200604/41 X-Sequence-Number: 24850 On Wednesday 05 April 2006 19:29, Tom Lane wrote: > Niklas Johansson writes: > > You could try > > > > SELECT foo.x, foo.y, title FROM > > (SELECT > > get_xy(SetSRID(sightings.location, 26910), 4326) AS foo, > > sightings.title > > FROM sightings > > WHERE sighting_id = 25) bar; > > Note however that the above is only a cosmetic answer: you avoid typing > the function call twice, but the planner will "flatten" the subquery > into the outer query and thereby end up with two evaluations anyway. > If you're really intent on avoiding the extra evaluation then you need > to do something to prevent the flattening from happening. One > handy trick is to use a LIMIT or OFFSET clause in the subquery as an > optimization fence: Thanks for the suggestions. This case is mostly for aesthetic reasons, or perhaps to prevent typing errors in the future (in case I have to modify the function call). Forming the sub-query that way will effectively solve my problem, even if it doesn't specifically aid in efficiency -- however my get_xy function is STABLE, so it shouldn't harm it too much (unsure about SetSRID); additionally, adding the OFFSET 0 is an interesting trick that I will also try. Thus, my final query: SELECT (xy).x, (xy).y, title FROM (SELECT get_xy(SetSRID(sightings.location, 26910), 4326) AS xy, sightings.title FROM sightings WHERE sighting_id = 25 OFFSET 0) bar; Thanks again. Mike. -- Michael Burke Engineering Technologies Canada Ltd. - http://www.engtech.ca/ michael@engtech.ca 1 (902) 628-1705