>
> We were planning to have the auto_explain extension added and set the
> log_min_duration to ~5 seconds and log_analyze to true. So that all the
> queries going above that time period will be logged and provide detailed
> information on the exact point of bottleneck. Will it be a good idea to se
On Mon, 4 Mar 2024 at 21:46, Greg Sabino Mullane wrote:
> On Mon, Mar 4, 2024 at 12:23 AM veem v 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
On Mon, Mar 4, 2024 at 12:23 AM veem v 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 diffe
On Mon, 2024-03-04 at 10:16 +0530, veem v wrote:
> So the partitioned table stats is nothing but the rolledover stats of all the
> partitions.
> As you mentioned, autoanalyze only works for child partitions but not the
> partition tables,
> so does it mean we have to schedule some jobs manually(t
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?
I am
On Mon, 4 Mar 2024 at 09:42, Laurenz Albe wrote:
>
> The only things that require manual ANALYZE are
>
> 1. partitioned tables (autoanalyze will collect statistics on the
>partitions, but not the partitioned table itself)
>
>
So the partitioned table stats is nothing but the rolledover stats
Laurenz Albe writes:
> The only things that require manual ANALYZE are
> ...
You missed one important exception: autovacuum/autoanalyze cannot
process temporary tables, because those are not accessible outside
the owning session. So you need to do those manually if it's
important for performance
On Mon, 2024-03-04 at 01:33 +0530, veem v wrote:
> We see in one of the RDS postgres instances, from pg_stat_user_tables ,
> the auto vacuum and auto analyze happening on the tables without our
> manual intervention.
That's exactly the idea behind autovacuum.
> So is auto vacuum analyze is suffi
Hi,
We see in one of the RDS postgres instances, from pg_stat_user_tables , the
auto vacuum and auto analyze happening on the tables without our manual
intervention.
So is auto vacuum analyze is sufficient to make sure optimal stats and
unbloated table structure in place or should we do it manual
