| From: | Rihad <grihad(at)gmail(dot)com> |
|---|---|
| To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Why doesn't autovacuum/analyze run in due time after calling pg_stat_reset? |
| Date: | 2023-08-21 16:31:08 |
| Message-ID: | 329abf6c-2165-f410-717f-c20b3dd0a3d7@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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:
>
>
>> Thanks for the detailed reply, no tables have custom settings.
>>
>> I need to make it clear once again that all autovac/analyze work as
>> expected when n_live_tup matches reality, i.e. when analyze has been
>> run on them since last reset.
>>
>> A way to fix this is to simply analyze the whole database. Before
>> doing that, while n_live_tup starts from basically 0 and grows based
>> on DB activity, these usual calculations of 10-20% table size for
>> vacuum/analyze don't work. They don't trigger autovac for most
>> tables, or do it much much later.
>>
>
> You still have not said or shown whether the other autovacuum settings
> are the default values or not. Assuming they are, then the only other
> explanation I can come up with is that there is a process or processes
> that are creating long running open transactions that prevent
> autovacuum from running on the affected tables.
>
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2023-08-21 16:45:48 | Re: The same prepared query yield "-1" the first six times and then "-1.0" |
| Previous Message | Adrian Klaver | 2023-08-21 16:23:06 | Re: Will PostgreSQL 16 supports native transparent data encryption ? |