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 1oIweT-0004oO-79 for pgsql-performance@arkaria.postgresql.org; Tue, 02 Aug 2022 18:29:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oIwdQ-0000PS-VG for pgsql-performance@arkaria.postgresql.org; Tue, 02 Aug 2022 18:28:52 +0000 Received: from makus.postgresql.org ([72.32.157.229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oIwZt-0001IN-MV for pgsql-performance@lists.postgresql.org; Tue, 02 Aug 2022 18:25:13 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oIveA-0003bD-Q2 for pgsql-performance@lists.postgresql.org; Tue, 02 Aug 2022 17:25:35 +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 272HPXg82659869; Tue, 2 Aug 2022 13:25:33 -0400 From: Tom Lane To: bruno da silva cc: pgsql-performance@lists.postgresql.org Subject: Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries In-reply-to: References: <2519232.1659455961@sss.pgh.pa.us> Comments: In-reply-to bruno da silva message dated "Tue, 02 Aug 2022 13:02:41 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2659867.1659461133.1@sss.pgh.pa.us> Date: Tue, 02 Aug 2022 13:25:33 -0400 Message-ID: <2659868.1659461133@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk bruno da silva writes: > Do you have a lot of especially long statements being tracked > in the pg_stat_statements view?* well, the view was showing the query > column null.* > * but looking on pgss_query_texts.stat there are very large sql > statements, of around ~ 400kb, multiple thousands. * Hm. We try to recover from such failures by (a) resetting all the view's query text fields to null and (b) truncating the file --- well, unlinking it and creating it as empty. It seems like (a) happened and (b) didn't. It's pretty hard to explain that from the code though. Are you quite sure this is a 9.5.21 version of the pg_stat_statements extension? Is it possible that the pg_stat_tmp directory has been made non-writable? regards, tom lane > Are there any other signs of distress > in the postmaster log, like complaints about being unable to write > pgss_query_texts.stat? *no, just complaints for reading it. * > Thanks > On Tue, Aug 2, 2022 at 11:59 AM Tom Lane wrote: >> bruno da silva writes: > After more investigation, we found that pgss_query_texts.stat of a size >> of > 2.2GB. and this deployment has a 32bit pg. >> >> Hm ... we've heard one previous report of pg_stat_statements' query text >> file getting unreasonably large, but it's not clear how that can come >> to be. Do you have a lot of especially long statements being tracked >> in the pg_stat_statements view? Are there any other signs of distress >> in the postmaster log, like complaints about being unable to write >> pgss_query_texts.stat? >> >> regards, tom lane >> > -- > Bruno da Silva