Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qacXE-009trR-U0 for pgsql-hackers@arkaria.postgresql.org; Mon, 28 Aug 2023 13:44:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qacXC-00CJuL-T8 for pgsql-hackers@arkaria.postgresql.org; Mon, 28 Aug 2023 13:44:02 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qacXC-00CJu4-Hw for pgsql-hackers@lists.postgresql.org; Mon, 28 Aug 2023 13:44:02 +0000 Received: from mail-lf1-x12d.google.com ([2a00:1450:4864:20::12d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qacX4-001XUF-Kh for pgsql-hackers@postgresql.org; Mon, 28 Aug 2023 13:44:01 +0000 Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-50079d148aeso4913117e87.3 for ; Mon, 28 Aug 2023 06:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693230233; x=1693835033; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=pMKq/ZE3fz5F6/xeB3N2e03rpLpXZmt5jf1zLJJZQEs=; b=WIrUyUH8IyQUfNAvtIxLE/evFtMXw54qABGjjZPuuEGHF8nFGBt6KiW3rjGAU499nV TGmqSbwIQMw5lf9hpuSDUQHuecwZdZ5R4GQqBax2QR8o2fyDaY22pm7hIWfISKzRpjyQ V36B3Mkzh59OdcdnSWNwW4sl2OywREH3OmNioHi3deqFixZRExWNvWFKHcjfqFbjV2/z BMHAaJMEtFb55m4et7i4zJcw4yoC2OLesK/aoRDIV18KSglHBmkcIUH5tnCq0T/HRjMZ z9zHJ9r2CH6dQZzsyH3H/OmoJhEyPcPzSnaJ9a3bYi3RgSjbh4kNPGHQ3cr9qXpyeB81 FcsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693230234; x=1693835034; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pMKq/ZE3fz5F6/xeB3N2e03rpLpXZmt5jf1zLJJZQEs=; b=Cx9GnY8jfr02Iaxd3FfdwSvIQlSN3W3jjBPO1SR6MTCZeIdXOVvUIYhX832khWmjBX ODmK5/ucKDm7QdeqD/x/4kxr7JZ5TB6HVucbHBlTeLgDdCYN6sGh30F1eiZoiLuqO06U olqbKmiJC0sU9Npl9RSKp/mktMKgRry9LEMdqZWkiHBGERcM54w1nbTUrl/rTwQwLiLq 0oTyq4ALVs8bgg5UsICdpw05o8P9Pvi8ormZf8wI0mvLhyGpByhgSGov5VtydlBOpAp0 zWj5+c5H1y/OUZS5R4Sp5LpSVLzSfbv3MhG7cJehj+XSu9nIeB95K8NxE1+aewR6jG/B +ZGg== X-Gm-Message-State: AOJu0YyTEWOhRSYTg5qgy+CGbkCKhjLqabnLzif+o0V5Qk3gJSZqEFKp QTXFLkP+RAN7OrEiUMydd+zivAa59mdkFgox5PE= X-Google-Smtp-Source: AGHT+IFfRZttLjdrxWYcLO5EvwaNhtkPP27Zu5YUWFUzF/1Eo4NcB7vj+sb9OdGZZCc7DPvdGxjgqXdieiXJ7vIYWJk= X-Received: by 2002:ac2:4c2e:0:b0:500:95d8:1b01 with SMTP id u14-20020ac24c2e000000b0050095d81b01mr9301644lfq.65.1693230233451; Mon, 28 Aug 2023 06:43:53 -0700 (PDT) MIME-Version: 1.0 References: <20221221101846.7zsi7lscnm5ediik@alvherre.pgsql> <1350682.1671635927@sss.pgh.pa.us> <4191508.1674157166@sss.pgh.pa.us> <349124.1674185509@sss.pgh.pa.us> <20230207180855.xy5m4puwh5gzd7xy@awork3.anarazel.de> <1274885.1680558101@sss.pgh.pa.us> <9D23D8BB-83EE-451E-95C1-CF42ADB76869@yesql.se> In-Reply-To: From: Robert Haas Date: Mon, 28 Aug 2023 09:43:41 -0400 Message-ID: Subject: Re: generic plans and "initial" pruning To: Amit Langote Cc: Alvaro Herrera , Andres Freund , Daniel Gustafsson , David Rowley , Jacob Champion , PostgreSQL Hackers , Thom Brown , Tom Lane Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Aug 11, 2023 at 9:50=E2=80=AFAM Amit Langote wrote: > After removing the unnecessary cleanup code from most node types=E2=80=99= ExecEnd* functions, one thing I=E2=80=99m tempted to do is remove the func= tions that do nothing else but recurse to close the outerPlan, innerPlan ch= ild nodes. We could instead have ExecEndNode() itself recurse to close out= erPlan, innerPlan child nodes at the top, which preserves the close-child-b= efore-self behavior for Gather* nodes, and close node type specific cleanup= functions for nodes that do have any local cleanup to do. Perhaps, we cou= ld even use planstate_tree_walker() called at the top instead of the usual = bottom so that nodes with a list of child subplans like Append also don=E2= =80=99t need to have their own ExecEnd* functions. I think 0001 needs to be split up. Like, this is code cleanup: - /* - * Free the exprcontext - */ - ExecFreeExprContext(&node->ss.ps); This is providing for NULL pointers where we don't currently: - list_free_deep(aggstate->hash_batches); + if (aggstate->hash_batches) + list_free_deep(aggstate->hash_batches); And this is the early return mechanism per se: + if (!ExecPlanStillValid(estate)) + return aggstate; I think at least those 3 kinds of changes deserve to be in separate patches with separate commit messages explaining the rationale behind each e.g. "Remove unnecessary cleanup calls in ExecEnd* functions. These calls are no longer required, because . Removing them saves a few CPU cycles and simplifies planned refactoring, so do that." --=20 Robert Haas EDB: http://www.enterprisedb.com