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 1siiPL-008NIs-Q5 for pgsql-general@arkaria.postgresql.org; Mon, 26 Aug 2024 22:41:55 +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 1siiPJ-00G9Z6-8b for pgsql-general@arkaria.postgresql.org; Mon, 26 Aug 2024 22:41:53 +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 1siiPI-00G9Yx-S2 for pgsql-general@lists.postgresql.org; Mon, 26 Aug 2024 22:41:53 +0000 Received: from mail-vs1-xe2e.google.com ([2607:f8b0:4864:20::e2e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1siiPF-001ere-6I for pgsql-general@lists.postgresql.org; Mon, 26 Aug 2024 22:41:52 +0000 Received: by mail-vs1-xe2e.google.com with SMTP id ada2fe7eead31-498c4f251ffso1700359137.3 for ; Mon, 26 Aug 2024 15:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724712109; x=1725316909; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9882MFJ/3FOZrkN/3hKBvWWpCmV5QofbLr5ZW7cf6qk=; b=DVYtVLsFZKaE2oUMMqXOYsoiL1+USh5ZrtUNrRXy4OtWr0dTWGm4r83H1WXx45aqX/ dfPHx5CFyk5TlG1et0exdEwdawnVz1PwpY2X2xSqKGY+nVexv0KZbNCYrnpYCQc1gtSn xbF8R0Ota3xw96TqUeqbry41Nps/usVf7P0YLTdZsSMAgDfgP+6dRZCnicP0b4LrtHBI RoMkjm6x4SXwhWIWk4Eb45ZR646M0IvsT4jUgRnbNm/ldQGU/RHunl/ocghHUus1kN/N TyzVtcdLy02ewmQbMMp/2CGbXoHB4l0dvp1P2iYaiOWb0HkAafEWqqMP8G6vQaYf6x6+ u8LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724712109; x=1725316909; h=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=9882MFJ/3FOZrkN/3hKBvWWpCmV5QofbLr5ZW7cf6qk=; b=LeaXMpy7JUwaigIciACTZOUa4/Mq/KnVqNsvaokaEnn1rYc5xSKK30jn9LEU6kHC/T KyZrMM2n6CR8lAM+3lykd+amnWGweawugwBVTPIhOpsj6Ox1TWMqIAee0JQpYkVy8dM5 k3GKfulo2NBATnaGRCtVxIS7TXxwzJWn6NusInpj2WzGNO7v80T+3V0mcwbYRwOfOr4g FwVaHUqspgSs1h7ga2ouYx+dNkHQT2y9GEtBMtgJetwvBQtDitFCrw6j/58SNdg7RnmE almoMKBtfDVizDuFYwT9PCb88jRCT9QpsLxbFwqqXgezZjXFn/bpTkJAPdvynnR5qP2F 6E2Q== X-Gm-Message-State: AOJu0YxJemX0Pnqx+QEg2Ox3kHUUej696Vyv9aO5ylYSEx71pu8SGTXa MJGn5u80h7JeniigquCWOGOKxjJO6GIf1LvXetfqdwOdeiWSQ59FSVzYDWF+IA2btYfTRqa99fq 3k3de9lNDwu6DfWUUg5UMlY1hyWw= X-Google-Smtp-Source: AGHT+IE/t/YHP6ib+majsOueW+WnNCEpi6SNVGnDGNaNXdNhU0OSFnDVY6xrGYENM9zpCEQ8jmF5lDWY0iXdTkbwq9k= X-Received: by 2002:a05:6102:d93:b0:498:c11b:7a5f with SMTP id ada2fe7eead31-49a3bb86025mr1373749137.5.1724712108575; Mon, 26 Aug 2024 15:41:48 -0700 (PDT) MIME-Version: 1.0 References: <7e0e289f-c92d-40cc-bf46-162d484a5df4@aklaver.com> In-Reply-To: <7e0e289f-c92d-40cc-bf46-162d484a5df4@aklaver.com> From: nikhil raj Date: Tue, 27 Aug 2024 04:11:36 +0530 Message-ID: Subject: Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables. To: Adrian Klaver Cc: "pgsql-generallists.postgresql.org" , NIKITA PATEL , Patel Khushbu Content-Type: multipart/alternative; boundary="0000000000009252f906209dd415" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000009252f906209dd415 Content-Type: text/plain; charset="UTF-8" Hi Adrian, Thanks for the quick response. I've already performed a vacuum, reindex, and analyze on the entire database, but the issue persists. As you can see from the execution plan, the time difference in PostgreSQL 16 is still significantly higher, even after all maintenance activities have been completed. It seems there might be a bug in PostgreSQL 16 where the performance of queries on *information_schema* tables is degraded. As both the tables are postgres system tables https://explain.depesz.com/s/bdO6b :-PG13 https://explain.depesz.com/s/bpAU :- PG16 On Tue 27 Aug, 2024, 3:40 AM Adrian Klaver, wrote: > On 8/26/24 14:49, nikhil raj wrote: > > Hi All, > > > > I've encountered a noticeable difference in execution time and query > > execution plan row counts between PostgreSQL 13 and PostgreSQL 16 when > > running a query on |information_schema| tables. Surprisingly, PostgreSQL > > 16 is performing slower than PostgreSQL 13. > > Did you run ANALYZE on the Postgres 16 instance? > > > *4PostgreSQL 13.14 (PostgreSQL 13.14 on x86_64-pc-linux-gnu, compiled by > > gcc 11.4.0, 64-bit)* > > Execution plan: PG13.14 Execution Plan > > > > > > *PostgreSQL 16.4 (PostgreSQL 16.4 on x86_64-pc-linux-gnu, compiled by > > gcc 11.4.0, 64-bit)* > > Execution plan: PG16.4 Execution Plan > > > > > Use: > > https://explain.depesz.com/ > > It is easier to follow it's output. > > > > > > > Has anyone else experienced similar behavior or could provide insights > > into why PostgreSQL 16 might be slower for this query? Any advice or > > suggestions for optimization would be greatly appreciated. > > Yes when ANALYZE was not run on a new instance. > > > > > Thank you! > > > > NOTE:- PFA the raw file of explain and analyze below. > > > > > > > > > > -- > Adrian Klaver > adrian.klaver@aklaver.com > > --0000000000009252f906209dd415 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Adrian,

Thanks for the quick response.

I've already performed a vacuu= m, reindex, and analyze on the entire database, but the issue persists. As = you can see from the execution plan, the time difference in PostgreSQL 16 i= s still significantly higher, even after all maintenance activities have be= en completed.

It seems there might be= a bug in PostgreSQL 16 where the performance of queries on=C2=A0informa= tion_schema=C2=A0tables is degraded. As both the tables are postgres sy= stem tables=C2=A0

https://explain.depesz.com/s/bdO6b=C2=A0 :-PG13


On Tue 27 Aug, 2024, 3:40 = AM Adrian Klaver, <adrian.k= laver@aklaver.com> wrote:
On= 8/26/24 14:49, nikhil raj wrote:
> Hi All,
>
> I've encountered a noticeable difference in execution time and que= ry
> execution plan row counts between PostgreSQL 13 and PostgreSQL 16 when=
> running a query on |information_schema| tables. Surprisingly, PostgreS= QL
> 16 is performing slower than PostgreSQL 13.

Did you run ANALYZE on the Postgres 16 instance?

> *4PostgreSQL 13.14 (PostgreSQL 13.14 on x86_64-pc-linux-gnu, compiled = by
> gcc 11.4.0, 64-bit)*
> Execution plan: PG13.14 Execution Plan
> <https://explain.dalibo.com/pla= n/ag1a62a9d47dg29d>
>
> *PostgreSQL 16.4 (PostgreSQL 16.4 on x86_64-pc-linux-gnu, compiled by =
> gcc 11.4.0, 64-bit)*
> Execution plan: PG16.4 Execution Plan
> <https://explain.dalibo.com/pla= n/4c66fdfbf2hf9ed2>


Use:

https://explain.depesz.com/

It is easier to follow it's output.

>
>
> Has anyone else experienced similar behavior or could provide insights=
> into why PostgreSQL 16 might be slower for this query? Any advice or <= br> > suggestions for optimization would be greatly appreciated.

Yes when ANALYZE was not run on a new instance.

>
> Thank you!
>
> NOTE:-=C2=A0 PFA the raw file of explain and analyze below.
>
>
>
>

--
Adrian Klaver
adrian.klaver@aklaver.com

--0000000000009252f906209dd415--