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 1sj9Oi-00Fkfs-3b for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Aug 2024 03:31: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 1sj9Og-00GGru-5F for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Aug 2024 03:31: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 1sj9Of-00GGrm-R5 for pgsql-hackers@lists.postgresql.org; Wed, 28 Aug 2024 03:31:02 +0000 Received: from mail-yw1-x112d.google.com ([2607:f8b0:4864:20::112d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sj9Oc-001rAU-Qb for pgsql-hackers@lists.postgresql.org; Wed, 28 Aug 2024 03:31:01 +0000 Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-6b5b65b1b9fso52359477b3.2 for ; Tue, 27 Aug 2024 20:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724815858; x=1725420658; darn=lists.postgresql.org; 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=uWTByzD8wkXs7Zr8OWbQGeSVUQGFiCcNRjAfoY56R9k=; b=AbgdoGlG9FdiyS9sLD0CFiDDQsweSi2hxMZqSI5D0b4PU9BwlFUwTk4bZw+1fceWJR M0upL9n1YVc9l97qThxcDC3ywDrgE58zsMHNkz3XtfPI2ShnMUNY15jq96Y+gHZDtkn5 icwJ5gBSCoIxXLD3aRRw2+WrhNNqEx1+WKC16BtHFY5emJWyyaXWIwcauqRn3c3rDUc2 KsD2G+H6W7ZQbrg8+e2DOG/gZ8ZfOlhr6hnI/eJYV+Bec6Ju7t5a7sDXRSXJwkj2e9pf VhJ1EiXiSkQG4I0/lBudf8KMwXmURb2/9MNu73D2iooVaDcKTjbZujujE1pE6JbMs2xt Gs+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724815858; x=1725420658; 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=uWTByzD8wkXs7Zr8OWbQGeSVUQGFiCcNRjAfoY56R9k=; b=JF4JEcIn6QWTJF+LzXv1uNIaYer0qFaSgYrJwnekgP74Gd8qBWyjZKUVQgbpEsGA30 upa0zc6TJk2tgYUJqP9X2gc+2gxguDBA/h8W3AoOqC30JGajwJRmvpz8qJdx67MK81xK LxYm4apjmP8KIk0OKTT9ysuNlRSRZzc8DQxaNagUzBC0PeqccDD/hkc5W5YHPeQjDx5I bASXoilgQP+sPiRzKlsiCQCuHPLFLa3/d4UQEQKng1tLza6EmkdOqp6fK8DqDFC07Zx1 nE+xPOKDJnZ4C+rVOjtlrtPKlJW+GQn03d/BAag2SM5lJnDsF6fmBpdPJKC7pbHUInaG BKTQ== X-Forwarded-Encrypted: i=1; AJvYcCV/cHHIt+8Jjyctmp2ykqfuxEE1/S5hwcK089mnpInOvI76d1VaKEn/xytC74cvCX22DXgKzvomCxysw7Cm@lists.postgresql.org X-Gm-Message-State: AOJu0YyAc+N8DSWjUAA5GhTDGvsSJAm3DttijCfzQ2xn5Twdb4IQVVMT PREYzTfc3LtPZXF4Qawk2rlMgk3TuqvImZgHwLFuzGs6HE8eza5MdbwsbkX2qmlzF8lV/aGtSEe gKFTvVR/pSHf9+9fM4+pUY3W9z3w= X-Google-Smtp-Source: AGHT+IHXZemmOGjugg6AsPhM5Pd5GH/Y1MBBnVGzDGg9Hp13Yutt6Ro7vTtX01D6RFBshowTUZn0vKOz1rnNcGP41Pw= X-Received: by 2002:a05:690c:318d:b0:6b2:7bd8:d7b8 with SMTP id 00721157ae682-6c62906583fmr120737957b3.39.1724815858397; Tue, 27 Aug 2024 20:30:58 -0700 (PDT) MIME-Version: 1.0 References: <2962669.1724722813@sss.pgh.pa.us> <2965760.1724724227@sss.pgh.pa.us> <3104695.1724775341@sss.pgh.pa.us> <3147330.1724795532@sss.pgh.pa.us> In-Reply-To: <3147330.1724795532@sss.pgh.pa.us> From: Richard Guo Date: Wed, 28 Aug 2024 11:30:45 +0800 Message-ID: Subject: Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables. To: Tom Lane Cc: David Rowley , nikhil raj , pgsql-hackers@lists.postgresql.org 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 Wed, Aug 28, 2024 at 5:52=E2=80=AFAM Tom Lane wrote: > I realized that actually we do have the mechanism for making that > work: we could apply add_nulling_relids to the expression, if it > meets those same conditions. I think this should work, as long as we apply add_nulling_relids only to Vars/PHVs that belong to the subquery in this case, because only those Vars/PHVs would be nulled by the outer joins contained in the nullingrels. > If we go forward with this, I'm thinking about > changing add_nulling_relids' API contract to say "if target_relid > is NULL then all level-zero Vars/PHVs are modified", so that we > don't need that relid set in non-LATERAL cases. +1. In LATERAL case, we can always find the subquery's relids in rcon->relids. In non-lateral case, any level-zero Vars/PHVs must belong to the subquery - so if we change add_nulling_relids' API to be so, we do not need to have rcon->relids set. Thanks Richard