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 1uuDHY-004qrk-3C for pgsql-general@arkaria.postgresql.org; Thu, 04 Sep 2025 16:57:57 +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 1uuDHX-000hDr-7Y for pgsql-general@arkaria.postgresql.org; Thu, 04 Sep 2025 16:57:55 +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 1uuDHW-000hDj-TX for pgsql-general@lists.postgresql.org; Thu, 04 Sep 2025 16:57:55 +0000 Received: from mail-ej1-x630.google.com ([2a00:1450:4864:20::630]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uuDHV-000XSo-1T for pgsql-general@lists.postgresql.org; Thu, 04 Sep 2025 16:57:54 +0000 Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-b047f28a83dso170423166b.2 for ; Thu, 04 Sep 2025 09:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757005072; x=1757609872; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=p1+VK1XLxognYOpXxbj38go+3EX0OrxjdlX5f8CyDwM=; b=UltznNE9iQj1fUIBJ9xDpN9/kbEO3ZMC5xxiGpaUjFRk+gNVxg4HK3l8bijHB2A2vY EsiLHxjYOiJftI4tuLaaHPY5bk1c3azHEgVHfyW75qGBlgkIQiqwHjEa+uEEt1i21iU2 8lMHivWr/zTABv4CjP7iQQdoT4BGZ9pcCDv/E7u5XeQOrFhzwKfM0u4Tq2arMpb/OgMv lm4BBHyJw1QmbWlBv8AaeCSGKOIY40FwVrBUeBqlQRb416HksxrCH/COwEhepkoluM0K IvXQWbTmlGbJ3K8mVhbTgTtezTMkdmVogtsFqqbFJIgGV6K53qi8gxUyz8QbkxBT9mf2 1MMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757005072; x=1757609872; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=p1+VK1XLxognYOpXxbj38go+3EX0OrxjdlX5f8CyDwM=; b=p/ScdG3rb0Ds5CUfM4juwnP44ugCe3x+eDy2WSHTOTYzACOiGElkAD8s1+W9VM8LZK GSiFE+FPXxYJQJhO/9Fe23pVtG6L8b+19Xa2gyijqaPJXM+FEkPw1Sk5/EUtZn0pelH8 TJgq1jezhbvOz+hQQqo/4pagVkKYkW0u7IBfGs5+hm0OaqRBXDJUfIT7caeaS6DTxny0 up0kSxfmlkArJZXkcXtvFziarxyb18RZGa8qRdLddSYT8GUz7kCuNiMZ6cWtVNc6fmZU IIgTxVH39AUFlHtlK73ejq+3I+LPeK4ZxCcSWqI/goy5xzpZcJtHcv5hvKCKQ1jubMWV dzGw== X-Gm-Message-State: AOJu0YziV01D0n+GW65eqBy1nzQ7+PSjdXiNSmbgVFGhFna6RqPDqizX W/4Y0agJOHVfdy22MpCkaD+9CVKlSkhrGEGxb2vjelUjKlYg7Xd64OhorP8nqZDaspDUkVLyeqf 7FBFaHwaYQEsnIpjWoMdMjC1gkqlFN/3N/D3RTBg= X-Gm-Gg: ASbGncu+iyQJOYWY/YOAatUxY2XuvgfGoFAxbt1jIEZjeeKEoqE4r6kQuy0WTUwgd0V CmgrDee1iq82BlpT8vKhlxFIzOO2UXkA7whY7J82NcdeCjqZjuj3toDw7COOeZCm/4uoADO90em q5gTwzvtA3mFlGQgEguQOIkDsS7oWzeOmYj7RaSixMs7fkgu6LQp9N80g0B9jiRXgKdoqIMqMta j+S6+ZIcdq+Kb5fF/is5HzVZAviCkrDst1KyrN2PbjfYhbv X-Google-Smtp-Source: AGHT+IGpaV5yjBOh2dKBJ8b1IbefNwVvUIF1Gf9E05s37CiymWpCX/zcbZP/vRO5P/xMRu4/QPFvGKxRFMVxlqASRUI= X-Received: by 2002:a17:907:2da5:b0:b04:6412:95ec with SMTP id a640c23a62f3a-b0464129a88mr801638666b.10.1757005071510; Thu, 04 Sep 2025 09:57:51 -0700 (PDT) MIME-Version: 1.0 From: veem v Date: Thu, 4 Sep 2025 22:27:39 +0530 X-Gm-Features: Ac12FXy-d90kXGhds1MT0gL_vrSCNU0jiVRHMXpN46dF-0jJo6PqDcQPSImxrmE Message-ID: Subject: Debugging query performance in postgres To: pgsql-general Content-Type: multipart/alternative; boundary="00000000000027f16b063dfc9f39" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000027f16b063dfc9f39 Content-Type: text/plain; charset="UTF-8" Hello, We have a situation in which we had a dml query within a procedure that was running fine but suddenly the plan flipped and it started running longer. It took us a good amount of time to identify the cause and fix it. So I have below questions, 1)Do we have any data dictionary view or query available which gives us information on what were the queryids those are executing from within a procedure and how much time they are taking? 2)Also how to identify , if any specific queries has opted a different plan today as compared to past executions and also response time increased because of that? Regards Veem --00000000000027f16b063dfc9f39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
We have a situation in which we had a dml query = within a procedure that was running fine but suddenly the plan flipped and = it started running longer. It took us a good amount of time to identify the= cause and fix it. So I have below questions,
1)Do we have any data dict= ionary view or query available which gives us information on what were the = queryids those are executing from within a procedure and how much time they= are taking?
2)Also how to identify , if any specific queries has opted = a different plan today as compared to past executions and also response tim= e increased because of that?

Regards
Veem
--00000000000027f16b063dfc9f39--