Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jGQCA-0001wN-J3 for pgsql-hackers@arkaria.postgresql.org; Mon, 23 Mar 2020 16:44:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jGQC9-0008TA-CV for pgsql-hackers@arkaria.postgresql.org; Mon, 23 Mar 2020 16:44:57 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1jGQC8-0008Sy-Uv for pgsql-hackers@lists.postgresql.org; Mon, 23 Mar 2020 16:44:57 +0000 Received: from mail-qt1-x843.google.com ([2607:f8b0:4864:20::843]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jGQC4-0001Pk-Mi for pgsql-hackers@lists.postgresql.org; Mon, 23 Mar 2020 16:44:56 +0000 Received: by mail-qt1-x843.google.com with SMTP id d12so9796213qtj.4 for ; Mon, 23 Mar 2020 09:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=qKlfJcYk+c5I2YePxQEMVPYnQXYjPh2CYxisF/yejBw=; b=ZKdVd/jObF+VY18YRB/TYzy/72F+3ch8WDvfHuoXHTyUIcWCfq61wOAqN/Kj2IiKZe pFTzh6jPP6rnnH24raEY5A8r7Ib1+k17Ep0KyqOn6yw16ph8nU9rZ2XczENwvDuYEWPv 1LCeenysl8i0rj6Gg9iQpii5LLAETF8pE+K8BkJ4pIzjF+UwVCDrh3wCi8Ec6CV3uvBX nmb3bMSwgwx+DivLqzmSZd41I2lUtw1UWKR4HmjwmGo7lydnftK+xjbZTu3Jzi5c5TNp lbM10l7TAmnjL76oichs8w5TaeMC5YpiX3Vfj9KgLAaMbly46XoEhEbR9p15J4074Cos oxNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=qKlfJcYk+c5I2YePxQEMVPYnQXYjPh2CYxisF/yejBw=; b=I2jS8GK3bIDDPeietMSg2aHDuVj1Pb4FWdndBx/Q48ZM67KxWVnXo0n4xOurGe1Gix HgQjui2Py2UNgMf68gPZfEgUsIOzhul3J5LdliJqFxbxGkjBKHrxbmCUzU9oHb69bDQo uKTOR9u9Ybzu1rHX56LpjkT8ylObtY9DdhoHEwG5pTrFX2EKFlxwNfmGTrU9EntM0U2x JkiacibZSM3tSaNhXn52NUtLsQSLzTKD5Opg5vqEUhE16BsY6NB3p55lSdqL8XHOUPq9 uq/SG6yLSK12qrAB4meMO7N663P+324GPBu9CuqctI+u+YcssLwr2dQgDAK3nq7Tvp7z vCvQ== X-Gm-Message-State: ANhLgQ0XPnNImCvd5vCsHAP9DX+Hw9aM+nX2a9lV45KjKoGiHaOdrqWy d0+eVVHxvczz+259sCPe2jv4xQ== X-Google-Smtp-Source: ADFU+vuOuhDjjQscgbW3T1b02w9VuyteuGdTxS6sFQTvlV5qnNR2xBUYKtdjcmkHlyHEeoW7GN8Ppw== X-Received: by 2002:ac8:6c6:: with SMTP id j6mr22125975qth.231.1584981890045; Mon, 23 Mar 2020 09:44:50 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([201.186.208.119]) by smtp.gmail.com with ESMTPSA id s36sm12587205qtb.28.2020.03.23.09.44.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Mar 2020 09:44:49 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 7739E300825; Mon, 23 Mar 2020 13:44:46 -0300 (-03) Date: Mon, 23 Mar 2020 13:44:46 -0300 From: Alvaro Herrera To: James Coleman Cc: Tomas Vondra , Michael Paquier , Rafia Sabih , Peter Geoghegan , Simon Riggs , Shaun Thomas , Dmitry Dolgov <9erthalion6@gmail.com>, Alexander Korotkov , Tom Lane , PostgreSQL Developers , andreas@proxel.se Subject: Re: [PATCH] Incremental sort (was: PoC: Partial sort) Message-ID: <20200323164446.GA6911@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-Mar-22, James Coleman wrote: > One question I have while I work on that: I've noticed some confusion > in the patch as to whether we should refer to the node below the > incremental sort node in the plan tree (i.e., the node we get tuples > from) as the inner node or the outer node. Intuitively I'd expect to > call it the inner node, but the original patch referred to it > frequently as the outer node. The outerPlanState/innerPlanState macro > comments don't offer a lot of clarification though they're "to avoid > confusion" about right/left inner/outer. I suppose if the > outerPlanState macro is working here the correct term should be outer? I think the inner/outer distinction comes from join nodes wanting to distinguish which child drives the scan of the other. If there's a single child, there's no need to make such a distinction: it's just "the child". And if it's the only child, conventionally we use the first one, which conventionally is (for us westerners) the one on the left. This view is supported by the fact that outerPlanState() appears 113 times in the code whereas innerPlanState() appears only 27 times -- that is, all plan types that use only one child use the outer one. They could use either, as long as it does that consistently, I think. Therefore the term should be "outer". It's not "outer" to the parent incremental sort; it's just the "outer" of its two possible children. I think. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services