Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bkdap-0002Y3-Jn for pgsql-hackers@arkaria.postgresql.org; Thu, 15 Sep 2016 20:49:11 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bkdap-0004t8-4o for pgsql-hackers@arkaria.postgresql.org; Thu, 15 Sep 2016 20:49:11 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bkdan-0004sO-FC for pgsql-hackers@postgresql.org; Thu, 15 Sep 2016 20:49:09 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bkdag-0002BQ-Fb for pgsql-hackers@postgresql.org; Thu, 15 Sep 2016 20:49:08 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id u8FKmxo5014139; Thu, 15 Sep 2016 16:48:59 -0400 From: Tom Lane To: Andres Freund cc: pgsql-hackers@postgresql.org Subject: Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) In-reply-to: <20160915203222.27fmxjme5gehluei@alap3.anarazel.de> References: <20160912165403.vshr7tazhr6wrpp4@alap3.anarazel.de> <8136.1473701180@sss.pgh.pa.us> <20160912173815.dlew2xsblcso33sw@alap3.anarazel.de> <17324.1473716167@sss.pgh.pa.us> <20160912220705.b77smzorutebnbee@alap3.anarazel.de> <19682.1473719703@sss.pgh.pa.us> <20160912231144.f3nseocp274iq7wg@alap3.anarazel.de> <23413.1473723322@sss.pgh.pa.us> <20160912234630.caueobrrbg5vse5y@alap3.anarazel.de> <557.1473895705@sss.pgh.pa.us> <20160915203222.27fmxjme5gehluei@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Thu, 15 Sep 2016 13:32:22 -0700" Date: Thu, 15 Sep 2016 16:48:59 -0400 Message-ID: <14138.1473972539@sss.pgh.pa.us> X-Pg-Spam-Score: -4.2 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Andres Freund writes: > Hm. One thing I wonder about with this approach, is how we're going to > handle something absurd like: > SELECT generate_series(1, generate_series(1, 2)), generate_series(1, generate_series(2,4)); The patch that I posted would run both the generate_series(1, 2) and generate_series(2,4) calls in the same SRF node, forcing them to run in lockstep, after which their results would be fed to the SRF node doing the top-level SRFs. We could probably change it to run them in separate nodes, but I don't see any principled way to decide which one goes first (and in some variants of this example, it would matter). I think the LATERAL approach would face exactly the same issues: how many LATERAL nodes do you use, and what's their join order? I think we could get away with defining it like this (ie, SRFs at the same SRF nesting level run in lockstep) as long as it's documented. Whatever the current behavior is for such cases would be pretty bizarre too. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers