public inbox for [email protected]help / color / mirror / Atom feed
Debugging query performance in postgres 5+ messages / 3 participants [nested] [flat]
* Debugging query performance in postgres @ 2025-09-04 16:57 veem v <[email protected]> 2025-09-04 17:49 ` Re: Debugging query performance in postgres Adrian Klaver <[email protected]> 2025-09-04 23:21 ` Re: Debugging query performance in postgres Ron Johnson <[email protected]> 0 siblings, 2 replies; 5+ messages in thread From: veem v @ 2025-09-04 16:57 UTC (permalink / raw) To: pgsql-general <[email protected]> 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 ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Debugging query performance in postgres 2025-09-04 16:57 Debugging query performance in postgres veem v <[email protected]> @ 2025-09-04 17:49 ` Adrian Klaver <[email protected]> 2025-09-04 20:32 ` Re: Debugging query performance in postgres veem v <[email protected]> 1 sibling, 1 reply; 5+ messages in thread From: Adrian Klaver @ 2025-09-04 17:49 UTC (permalink / raw) To: veem v <[email protected]>; pgsql-general <[email protected]> On 9/4/25 09:57, veem v wrote: > 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, What was the cause? Postgres version Was there any major changes in the database e.g schema changes or quantity of data? Is autovacuum running? > 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? Take a look at: https://www.postgresql.org/docs/current/pgstatstatements.html > > Regards > Veem -- Adrian Klaver [email protected] ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Debugging query performance in postgres 2025-09-04 16:57 Debugging query performance in postgres veem v <[email protected]> 2025-09-04 17:49 ` Re: Debugging query performance in postgres Adrian Klaver <[email protected]> @ 2025-09-04 20:32 ` veem v <[email protected]> 2025-09-04 21:20 ` Re: Debugging query performance in postgres Adrian Klaver <[email protected]> 0 siblings, 1 reply; 5+ messages in thread From: veem v @ 2025-09-04 20:32 UTC (permalink / raw) To: Adrian Klaver <[email protected]>; +Cc: pgsql-general <[email protected]> On Thu, 4 Sept 2025 at 23:19, Adrian Klaver <[email protected]> wrote: > On 9/4/25 09:57, veem v wrote: > > 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, > > What was the cause? > > Postgres version > > Was there any major changes in the database e.g schema changes or > quantity of data? > > Is autovacuum running? > > > 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? > > Take a look at: > > https://www.postgresql.org/docs/current/pgstatstatements.html > > We didn't get the exact root cause why the plan flipped but we have to add additional filters to get rid of the performance issue. The version is 16. Yes, autovacuum running. We don't have any major changes. But if there was a significant change in quantity of data , Yet to check that. The pg_stats_statement does show the execution stats of the individual query execution , but doesnt show any historical plan deviation. Also the individual procedure and sql statement are logged into this view but i was wondering if there is an easy way to relate the sql text of the procedure with the underlying sqls running within the procedure? ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Debugging query performance in postgres 2025-09-04 16:57 Debugging query performance in postgres veem v <[email protected]> 2025-09-04 17:49 ` Re: Debugging query performance in postgres Adrian Klaver <[email protected]> 2025-09-04 20:32 ` Re: Debugging query performance in postgres veem v <[email protected]> @ 2025-09-04 21:20 ` Adrian Klaver <[email protected]> 0 siblings, 0 replies; 5+ messages in thread From: Adrian Klaver @ 2025-09-04 21:20 UTC (permalink / raw) To: veem v <[email protected]>; +Cc: pgsql-general <[email protected]> On 9/4/25 13:32, veem v wrote: > > On Thu, 4 Sept 2025 at 23:19, Adrian Klaver <[email protected] > > We didn't get the exact root cause why the plan flipped but we have to > add additional filters to get rid of the performance issue. Did you do an EXPLAIN ANALYZE before and after the changes? If so did you save the results and can you share them? > The version is 16. > Yes, autovacuum running. > We don't have any major changes. Except for the performance degradation, so something changed. > But if there was a significant change > in quantity of data , Yet to check that. > > The pg_stats_statement does show the execution stats of the individual > query execution , but doesnt show any historical plan deviation. Also > the individual procedure and sql statement are logged into this view but > i was wondering if there is an easy way to relate the sql text of the > procedure with the underlying sqls running within the procedure? The pg_stat_statements view has the following fields(among others): min_exec_time double precision max_exec_time double precision mean_exec_time double precision minmax_stats_since timestamp with time zone I could see a cron job that gathers the above data at regular intervals. Then you could track the query performance at a rough level. -- Adrian Klaver [email protected] ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Debugging query performance in postgres 2025-09-04 16:57 Debugging query performance in postgres veem v <[email protected]> @ 2025-09-04 23:21 ` Ron Johnson <[email protected]> 1 sibling, 0 replies; 5+ messages in thread From: Ron Johnson @ 2025-09-04 23:21 UTC (permalink / raw) To: pgsql-general On Thu, Sep 4, 2025 at 12:58 PM veem v <[email protected]> wrote: > 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. > That sounds like something that bit me once. Took a while to figure out, and was very puzzling. This list explained the problem and gave me the solution. If you run the same query multiple times in, after five executions, the PG query optimizer decides to use a generic plan. This disables that choice to use a generic plan: set plan_cache_mode = force_custom_plan; Setting that returned the procedures to their previously-rapid execution. -- Death to <Redacted>, and butter sauce. Don't boil me, I'm still alive. <Redacted> lobster! ^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2025-09-04 23:21 UTC | newest] Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-09-04 16:57 Debugging query performance in postgres veem v <[email protected]> 2025-09-04 17:49 ` Adrian Klaver <[email protected]> 2025-09-04 20:32 ` veem v <[email protected]> 2025-09-04 21:20 ` Adrian Klaver <[email protected]> 2025-09-04 23:21 ` Ron Johnson <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox