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 1v2HQT-0020Fq-5A for pgsql-general@arkaria.postgresql.org; Fri, 26 Sep 2025 23:00:29 +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 1v2HQQ-006TtZ-S5 for pgsql-general@arkaria.postgresql.org; Fri, 26 Sep 2025 23:00:27 +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 1v2HQQ-006TtR-FX for pgsql-general@lists.postgresql.org; Fri, 26 Sep 2025 23:00:27 +0000 Received: from mail-oo1-xc2a.google.com ([2607:f8b0:4864:20::c2a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v2HQO-0006Uc-2i for pgsql-general@lists.postgresql.org; Fri, 26 Sep 2025 23:00:26 +0000 Received: by mail-oo1-xc2a.google.com with SMTP id 006d021491bc7-6234995098eso1506765eaf.3 for ; Fri, 26 Sep 2025 16:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758927625; x=1759532425; 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=wiOm4PqM8WKyKYhu52a4jJejIc4XxxsDOfjsmvex898=; b=VIQvZgs33aIt2g4TIP4KPtqTciFY4fSPgsn8Jy7I8Ep223GKPUtoclo36XpclAjsSk cdl5w9/8LoXTraNOQF/sCyK48juwpR+GC5XXS9SJ9pcmkQk1g1ieAb7IeB8KzgXR4DlK z3amr7cEjkxy+YgskuRE9ulCOiiDbFbh1E2Hmc4SxmoGx/OTy6eyfAhWGjFG80cFtnaM MYeK9DtooUbCWsd+QZvfarvzLsdt5xX27JvR9qW4AdMv5HUd11y9W8znobL5N0ofq4Id IGk3MVs6h6ZvYNg3zXOOsbjvMD7yV9uW1hC5RYgCSEGI+YH6Kj8Q2g+Nlr0PIpkyCRB4 8tmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758927625; x=1759532425; 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=wiOm4PqM8WKyKYhu52a4jJejIc4XxxsDOfjsmvex898=; b=WAVHhVVD8FKv5wmdqgMLmQPfF1MLsS3zJSExXPMJqeWkvgeYIZI/Lzg89NK+tYe/a3 F9k2MuajXtB2ZWZ4JVgOPX7jhPZFXaJVFdRz8Ub7Lkf+uUoMOsGV50t/sYMvwziRJWID CgD5XHvc02RkKn14K5Xf80dylA2u1R7F/gnoDpZ0OssPwKOPwOWXMwt9NOaS1FqGH4LG wire/Y3Qdz0wmv/fGH0CzgftTKd4xjxc82ek57QdYtUF623fDvnvKR0bjDPzlgZ3U2SQ +J5w7e8fM3KaKuszKkWe93WNeXfr+vLw3N/d00Hq2jpWdw51HdpnF7rTV+0s2xB/9rRf +swA== X-Gm-Message-State: AOJu0YzMmZONaXAy+fS1viydtS2Ro85UJITurqCVHJtqiczYe7Dz8x8a LhByYVhlQuFVmv6nWDY7Req2iqvwRg8B8KIYCiKdejhvoyi3mMtTMP0eDwD+7VTorn6mEaeg8BY gfU9qrkE2hZLQyoGOuJ6qd4+hUYdXpwpR9Q== X-Gm-Gg: ASbGncuBDK6LrX0sbe0cw8XjKyYZSG6vhAcQXBPk4STw8Fo65ahKO/Ynoc37qgm8psD /MjeuPqr/TeOo2ePRrNGshZ44uM7LY7PJ9y0ftVVM144ZBmPgP7rqII9YaJewhWs5lIVXDxUPcQ u1lyo0nAZNQRWRn0Dh1HXFBlRYr+X2RF/7ldtapyoROuJL6nRygEeGj1OnMXUI0A8VYuN4448bS R1uN26/ X-Google-Smtp-Source: AGHT+IEuN/gW9tJDSodlpxd5yZb6xSQLCl1Mi9JQ7eNOycFsiyZ84+Oh9rdvFqG6ti+TmLGuKVvSfcQO1RiC9HSRdEk= X-Received: by 2002:a05:6820:827:b0:632:341e:e5f1 with SMTP id 006d021491bc7-63a38f0502cmr2572519eaf.3.1758927624715; Fri, 26 Sep 2025 16:00:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Fri, 26 Sep 2025 19:00:13 -0400 X-Gm-Features: AS18NWBAIXC4bmeyCzp7ZVcGAGCdYkotA4qPW6vBwid5MYmYFFR1uBhLnADgR0o Message-ID: Subject: Re: Correct query for monitor To: pgsql-general Content-Type: multipart/alternative; boundary="00000000000041bf56063fbc406b" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000041bf56063fbc406b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Sep 26, 2025 at 4:15=E2=80=AFPM veem v wrote: > 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 a= re > executed within the procedure) to quickly get the culprit sql? > Are there queries inside a cursor loop? > And say , we got the sql and saw a bad plan and we want to change the pla= n > or attach a good plan to that query , is there a possible way to do that = in > postgres? > >> PG does not support hints or "attaching plans to queries". --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --00000000000041bf56063fbc406b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Sep 26, 2025 at 4:15=E2=80=AFPM v= eem v <veema0000@gmail.com>= ; wrote:
Thank you so much fo= r the quick response. I have a follow up question on this as below,
If we want to identify, what exact query=C2=A0inside=C2=A0a pro= cedure 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 sq= ls(those are executed within the procedure) to quickly get the culprit sql?=

Are there queries inside a cur= sor loop?
=C2=A0
And say , we got the=C2=A0sql and saw a bad p= lan and we want to change the plan or attach a good plan to that query , is= there a possible way to do=C2=A0that in postgres?
=C2=A0
<= div>PG does not support hints or "attaching plans to queries".

--
Death to <Redact= ed>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
--00000000000041bf56063fbc406b--