Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pNbRu-0000N2-Uj for pgsql-admin@arkaria.postgresql.org; Thu, 02 Feb 2023 15:24:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pNbRt-0006AU-Oj for pgsql-admin@arkaria.postgresql.org; Thu, 02 Feb 2023 15:24:29 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pNbRt-00069w-EK for pgsql-admin@lists.postgresql.org; Thu, 02 Feb 2023 15:24:29 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pNbRr-0007S6-EO for pgsql-admin@lists.postgresql.org; Thu, 02 Feb 2023 15:24:29 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 312FOPFH1536296; Thu, 2 Feb 2023 10:24:25 -0500 From: Tom Lane To: Kenny Bachman cc: Pgsql-admin Subject: Re: too high planning time In-reply-to: References: Comments: In-reply-to Kenny Bachman message dated "Thu, 02 Feb 2023 12:54:34 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1536294.1675351465.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 02 Feb 2023 10:24:25 -0500 Message-ID: <1536295.1675351465@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Kenny Bachman writes: > EXPLAIN ANALYZE select > i."DefinitionId", > from > "T_WF_INSTANCE" i > where > i."InstanceId" =3D 10045683193; > QUERY PLAN > ------------------------------------------------------------------------= --------------------------------------------------------------------------= ------------------------------ > Index Scan using > "T_WF_INSTANCE_InstanceId_ApplicationCd_EntityStatusCd_idx" on > "T_WF_INSTANCE" i (cost=3D0.57..2.79 rows=3D1 width=3D34) (actual > time=3D2.522..2.522 rows=3D1 loops=3D1) > Index Cond: ("InstanceId" =3D '10045683193'::bigint) > * Planning Time: 8460.446 ms Execution Time: 2.616 ms* > (4 rows) It's hard to believe that such a simple query could take that long to plan. What I'm wondering is if the planner got blocked on some other session's exclusive lock. Not a lock on "T_WF_INSTANCE" itself, because we'd have got that lock during parsing before the "Planning Time" measurement starts. But there's going to be a physical access to the table's index to determine its tree height, so an ex-lock on the index could explain this. Or an ex-lock on catalogs, particularly pg_statistic. What else is going on in your database when this happens? regards, tom lane