Re: When manual analyze is needed

From: Greg Sabino Mullane <htamfids(at)gmail(dot)com>
To: veem v <veema0000(at)gmail(dot)com>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: When manual analyze is needed
Date: 2024-03-04 16:15:47
Message-ID: CAKAnmm+GK9x3O_qQ=nq94g5ukRA0a0Z89h-EZWD4MrjAubU-fg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Mar 4, 2024 at 12:23 AM veem v <veema0000(at)gmail(dot)com> wrote:

> Additionally if a query was working fine but suddenly takes a
> suboptimal plan because of missing stats , do we have any hash value column
> on any performance view associated with the queryid which we can refer to
> see past vs current plans difference and identify such issues quickly and
> fix it?
>

You can use auto_explain; nothing else tracks things at that fine a level.
You can use pg_stat_statements to track the average and max time for each
query. Save and reset periodically to make it more useful.

https://www.postgresql.org/docs/current/auto-explain.html

https://www.postgresql.org/docs/current/pgstatstatements.html

> I am not seeing any such column in pg_stat_activity or pg_stat_statements
> to hold hash value of the plan and also the query column is showing
> "<insufficient privilege>" for many of the entries, why so?
>

Ordinary users are not allowed to see what other people are running. You
can add a user to the pg_read_all_stats role to allow this:

GRANT pg_read_all_stats TO alice;

Oftentimes someone needing access to the stats also needs a little more
access, so consider the pg_monitor role as well. Both are documented here:

https://www.postgresql.org/docs/current/predefined-roles.html

Cheers,
Greg

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message sud 2024-03-04 19:39:16 Is partition pruning impacted by data type
Previous Message Koschicek-Krombholz, Bernhard 2024-03-04 16:01:46 Support for dates before 4713 BC