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 1v2Er5-001cVG-Qm for pgsql-general@arkaria.postgresql.org; Fri, 26 Sep 2025 20:15:47 +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 1v2Er3-005Zcw-2k for pgsql-general@arkaria.postgresql.org; Fri, 26 Sep 2025 20:15:45 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v2Er2-005Zcn-KB for pgsql-general@lists.postgresql.org; Fri, 26 Sep 2025 20:15:45 +0000 Received: from mail-ej1-x62d.google.com ([2a00:1450:4864:20::62d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v2Er0-0005Oc-2S for pgsql-general@lists.postgresql.org; Fri, 26 Sep 2025 20:15:44 +0000 Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-b33d785de7cso439105866b.1 for ; Fri, 26 Sep 2025 13:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758917740; x=1759522540; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=Ut08oghb9tHyMQHuGSFQ673Xs/yfHkf1lmJc0b0jJBs=; b=DzoY++0lSNUOAgVxddoxW8ZSL+OneI8gASUsTmEryEHLFBEjfsBnAPKTeK8t6w+d6E ubCmwMenBfXL6rvDhuNzHT19ga3VLBeYMit6PjKb1eC9bun9EE2BvcFOFxYOIQXUoqew gzDuvZDEOIm6TwRp5aAJHJquM4FRPxi/K7s1NlboK2dwwRCq2ovE644O13fWzvI2OknM Z/RQue1a+Whd920JSvVfMDQBCU5kjGDvsg6nw5LMT9EH3xQsqOLVy2iA316z8azYoLGP d2tgAOQofjvFMNUeNDNemfsp91uF3y+UqkGxhN5U5BbPVlV9DUtGxOwjQQ+JHZ7nuYKN /Iig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758917741; x=1759522541; h=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=Ut08oghb9tHyMQHuGSFQ673Xs/yfHkf1lmJc0b0jJBs=; b=xINsQrC4R7VrW1RgMoIGrCBigKWFjBZMcJq/xuqIijK/mdQr0364WNDxDK4do1jDiv LxAdiWVqHxb2XmcwhGQUP+LVXTIf11PaWzy5dsiP2/nScEmpPwWGPFDgCe3WK/XNzC3D 9JTK7oL7su7SV6G1vkNtyD/T9ZJptyG/49pym+sanMCpCFkm25YQ+w5CX/1w+rkwC+MQ 53+BBy7VmB9tunOKeKViYikcAEmMm/0RJtNr3mnpETHEB5eKecE9zBrbYeCuNZP/UO8A /213TewTk6a5uoR94OEVq0nl1zY1qrL6+RbodOFGGonj34tz0Mh0f468glYYeSXw3/II YQUg== X-Forwarded-Encrypted: i=1; AJvYcCWCfZySHXRA0jHbZ06qgHkCjMOcgcA+08n1F2mdOkySJCaEUyxgvHXpG8jBExuII3/iP1RErPBbN4vN/67l@lists.postgresql.org X-Gm-Message-State: AOJu0Yz9yapH2KxZXq+hUb6pKOKs8hruylsnPqWvHz4ER39MaRRBQzFD gFB1PaUYKxc98U43UpO3GF0maGR/+dFgauOA/CyNY+KbDg3hTmOUEoT4XnyOUr1bc7F0FXw+sMs bbNDQisfrTl4svl2r0QdMSV8qHFhWs1s= X-Gm-Gg: ASbGncvg35xt0UQvgw/8HDlf702XdZGBtkemR0Lg+zHGnUv6nb/NJ2Av+Qno3z10f3H eqZYLxTap9v6EPEFba1VQe2ot/nqOcJzIzkcFo9mKclHQGWSRZ3SDs0ufDSGaolba5tZHaMt6a9 IJrtUMZNh6n0wWvJWvuvvNr0b48JZ0zB43l9MtWsj5CjYOQ8ELnQJ0l/M7YxIFly4dncPhv4T1w W30YFl/UT/fLqHVPfW/AS84aEY2MRDZiSNGqQ== X-Google-Smtp-Source: AGHT+IHePMSzqZ2OgPYpfkRP8QNu22p9hmlJdzlNcxn/powLcQblXQDf85bk+aqSlQxIDreqLZcs+LJyEde8hmkxXW8= X-Received: by 2002:a17:906:c114:b0:b24:3a8b:9acb with SMTP id a640c23a62f3a-b34b1e7a54fmr937140666b.0.1758917740239; Fri, 26 Sep 2025 13:15:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: veem v Date: Sat, 27 Sep 2025 01:45:29 +0530 X-Gm-Features: AS18NWDhAL2INs67AYxGHjmZX3xy5ZgnDKd4kLL3L-4dJPfZLtdCIszi7WudAAE Message-ID: Subject: Re: Correct query for monitor To: Ron Johnson , pgsql-general Content-Type: multipart/alternative; boundary="000000000000189fe4063fb9f31c" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000189fe4063fb9f31c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you so much for the quick response. I have a follow up question on this as below, If we want to identify, what exact query inside a procedure is taking a longer time:- Using any pg_* views, Is there an easy way to tie the query_id of the procedure with the query_ids of the internal sqls(those are executed within the procedure) to quickly get the culprit sql? And say , we got the sql and saw a bad plan and we want to change the plan or attach a good plan to that query , is there a possible way to do that in postgres? On Fri, 26 Sept 2025 at 18:53, Ron Johnson wrote: > They seem reasonable to me. My stance is "run it until you want more > features, or find a flaw." > > On Fri, Sep 26, 2025 at 6:23=E2=80=AFAM veem v wrot= e: > >> Hello, >> We want to have monitoring on three things 1) If the database restarted >> or went down in the last few hours? 2)If the connections are high 3) Hig= h >> tablespace growth . Want to understand , if we can utilize below queries >> for the same or any flaws in this strategy? >> >> 1)SELECT >> CASE >> WHEN now() - pg_postmaster_start_time() < interval '12 hours' >> THEN 'ALERT: DB was restarted in the last 12 hours' >> ELSE 'OK' >> END AS status; >> >> 2)SELECT >> CASE >> WHEN conn_count > max_conn * 0.8 THEN >> 'ALERT: Connection usage is above 80%' >> ELSE >> 'OK: Connection usage is under control' >> END AS status, >> conn_count AS current_connections, >> max_conn AS max_connections, >> ROUND(conn_count * 100.0 / max_conn, 2) AS percent_used >> FROM ( >> SELECT >> COUNT(*) AS conn_count, >> (SELECT setting::int FROM pg_settings WHERE name =3D >> 'max_connections') AS max_conn >> FROM pg_stat_activity >> ) sub; >> >> 3)SELECT spcname, pg_size_pretty(pg_tablespace_size(oid)) AS size >> FROM pg_tablespace; >> >> Regards >> Veem >> > > > -- > Death to , and butter sauce. > Don't boil me, I'm still alive. > lobster! > --000000000000189fe4063fb9f31c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you so much for the quick response. I have a follow = up question on this as below,

If we want to identify, wh= at exact query=C2=A0inside=C2=A0a procedure is taking a longer time:- Using= any pg_* views, Is there an easy way to tie the query_id of the procedure = with the query_ids of the internal sqls(those are executed within the proce= dure) to quickly get the culprit sql? And say , we got the=C2=A0sql and saw= a bad plan and we want to change the plan or attach a good plan to that qu= ery , is there a possible way to do=C2=A0that in postgres?

<= div class=3D"gmail_quote gmail_quote_container">
On Fri, 26 Sept 2025 at 18:53, Ron Johnson <ronljohnsonjr@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
They seem= reasonable to me.=C2=A0 My stance is "run it=C2=A0until you want more= features, or find a flaw."

On Fri, Sep 26, 2025 at 6:23=E2=80=AFAM vee= m v <veema0000@= gmail.com> wrote:
Hello,
We want to have monitoring on three t= hings 1) If the database restarted or went down in the last few hours? 2)If= the connections are high 3) High tablespace growth . Want to understand , = if we can utilize below queries for the same or any flaws in this strategy?=

1)SELECT
=C2=A0 CASE
=C2=A0 =C2=A0= WHEN now() - pg_postmaster_start_time() < interval '12 hours' <= br>=C2=A0 =C2=A0 THEN 'ALERT: DB was restarted in the last 12 hours'= ;
=C2=A0 =C2=A0 ELSE 'OK'
=C2=A0 END AS status;
=C2=A0
= 2)SELECT
=C2=A0 =C2=A0 CASE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 WHEN conn_c= ount > max_conn * 0.8 THEN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= 'ALERT: Connection usage is above 80%'
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 ELSE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 'OK: Connection = usage is under control'
=C2=A0 =C2=A0 END AS status,
=C2=A0 =C2= =A0 conn_count AS current_connections,
=C2=A0 =C2=A0 max_conn AS max_con= nections,
=C2=A0 =C2=A0 ROUND(conn_count * 100.0 / max_conn, 2) AS perce= nt_used
FROM (
=C2=A0 =C2=A0 SELECT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 C= OUNT(*) AS conn_count,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (SELECT setting::int = FROM pg_settings WHERE name =3D 'max_connections') AS max_conn
= =C2=A0 =C2=A0 FROM pg_stat_activity
) sub;

3)SELECT spcname, pg_s= ize_pretty(pg_tablespace_size(oid)) AS size
FROM pg_tablespace;

= Regards
Veem


--
Death to <Redacted>, and butter sauce.Don't boil me, I'm still alive.
<Redacted> lobs= ter!
--000000000000189fe4063fb9f31c--