Re: Debugging query performance in postgres
От | Adrian Klaver |
---|---|
Тема | Re: Debugging query performance in postgres |
Дата | |
Msg-id | d3876cdc-9310-4fc1-9cd7-cd618251fe0e@aklaver.com обсуждение исходный текст |
Ответ на | Re: Debugging query performance in postgres (veem v <veema0000@gmail.com>) |
Список | pgsql-general |
On 9/4/25 13:32, veem v wrote: > > On Thu, 4 Sept 2025 at 23:19, Adrian Klaver <adrian.klaver@aklaver.com > > 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 adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: