'Re: Why doesn't autovacuum/analyze run in due time after calling pg_stat_reset?'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: Why doesn't autovacuum/analyze run in due time after calling pg_stat_reset?
From:       Rihad <grihad () gmail ! com>
Date:       2023-08-23 14:06:43
Message-ID: 3fafd9d5-ba37-8abf-ba46-ca51b6f706c9 () gmail ! com
[Download RAW message or body]

On 8/21/23 20:50, Adrian Klaver wrote:
> On 8/21/23 09:31, Rihad wrote:
> > On 8/21/23 20:17, Adrian Klaver wrote:
> > > On 8/21/23 09:09, Rihad wrote:
> > > > On 8/21/23 20:00, Adrian Klaver wrote:
> > > 
> 
> > 
> > Sorry, they are all as per default, commented out in the config.
> > 
> > There are no long running queries, otherwise they wouldn't be 
> > vacuumed/analyzed in due time after running first manual analyze, 
> > which updates n_live_tup to match reltuples.
> > 
> 
> My only remaining suggestion is to closely monitor the Postgres log 
> and see if provides a clue.
> 
I'm awfully sorry, I read the autovacuum manual carefully, it isn't 
n_live_tup, but reltuples that is taken into account during the calculation.


vacuum threshold = vacuum base threshold + vacuum scale factor * number of tuples

where the vacuum base threshold is autovacuum_vacuum_threshold 
<https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-THRESHOLD>, \
 the vacuum scale factor is autovacuum_vacuum_scale_factor 
<https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-SCALE-FACTOR>, \
                
*and the number of tuples is **|pg_class|**.**|reltuples|**.*


Your first suggestion was to RTFM.


[Attachment #3 (text/html)]

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 8/21/23 20:50, Adrian Klaver wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:0ebcc8ea-7f5a-d014-d53f-e078622be35d@aklaver.com">On
      8/21/23 09:31, Rihad wrote:
      <br>
      <blockquote type="cite">On 8/21/23 20:17, Adrian Klaver wrote:
        <br>
        <blockquote type="cite">On 8/21/23 09:09, Rihad wrote:
          <br>
          <blockquote type="cite">On 8/21/23 20:00, Adrian Klaver wrote:
            <br>
          </blockquote>
          <br>
        </blockquote>
      </blockquote>
      <br>
      <blockquote type="cite">
        <br>
        Sorry, they are all as per default, commented out in the config.
        <br>
        <br>
        There are no long running queries, otherwise they wouldn't be
        vacuumed/analyzed in due time after running first manual
        analyze, which updates n_live_tup to match reltuples.
        <br>
        <br>
      </blockquote>
      <br>
      My only remaining suggestion is to closely monitor the Postgres
      log and see if provides a clue.
      <br>
      <br>
    </blockquote>
    <p>I'm awfully sorry, I read the autovacuum manual carefully, it
      isn't n_live_tup, but reltuples that is taken into account during
      the calculation.</p>
    <p><br>
    </p>
    <pre class="programlisting">vacuum threshold = vacuum base threshold + vacuum \
scale factor * number of tuples </pre>
    <p>where the vacuum base threshold is <a class="xref"
href="https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-THRESHOLD">autovacuum_vacuum_threshold</a>,
  the vacuum scale factor is <a class="xref"
href="https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-SCALE-FACTOR">autovacuum_vacuum_scale_factor</a>,
                
      <b>and the number of tuples is </b><b><code \
class="structname">pg_class</code></b><b>.</b><b><code  \
class="structfield">reltuples</code></b><b>.</b></p>  <p></p>
    <p><br>
    </p>
    <p>Your first suggestion was to RTFM.<br>
    </p>
  </body>
</html>



[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic