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.96) (envelope-from ) id 1vh9cS-00AUJf-39 for pgsql-performance@arkaria.postgresql.org; Sat, 17 Jan 2026 16:57:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vh9cQ-009COo-0q for pgsql-performance@arkaria.postgresql.org; Sat, 17 Jan 2026 16:57:46 +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.96) (envelope-from ) id 1vh9cP-009COf-33 for pgsql-performance@lists.postgresql.org; Sat, 17 Jan 2026 16:57:46 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vh9cK-0011PS-1U for pgsql-performance@lists.postgresql.org; Sat, 17 Jan 2026 16:57:45 +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 60HGvbYk2147131; Sat, 17 Jan 2026 11:57:37 -0500 From: Tom Lane To: "Lillian Berry" cc: pgsql-performance@lists.postgresql.org, infra@pluralkit.me Subject: Re: Slow queries on simple index In-reply-to: References: Comments: In-reply-to "Lillian Berry" message dated "Sat, 17 Jan 2026 14:58:01 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2147129.1768669057.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sat, 17 Jan 2026 11:57:37 -0500 Message-ID: <2147130.1768669057@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "Lillian Berry" writes: > Logs on our PostgreSQL cluster show frequent slow reads on a simple quer= y by unique index. = > This issue has been present for some years, and survived multiple server= moves as well as PostgreSQL version upgrades. > Vacuuming or reindexing the table does not seem to help. What else is going on in that database? The fact that you show several different sessions suffering similar delays at almost the same time seems suspicious to me. I'm wondering if something is taking an exclusive lock on that table and then sitting on it for a second or two. regards, tom lane