Re: another autovacuum scheduling thread

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Sami Imseih <samimseih(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jeremy Schneider <schneider(at)ardentperf(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: another autovacuum scheduling thread
Date: 2025-10-27 16:06:26
Message-ID: aP-YgrcPi0EhgR9x@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Oct 26, 2025 at 02:25:48PM +1300, David Rowley wrote:
> Thanks. I've just had a look at it. A few comments and questions.

Thanks.

> 1) The subtraction here looks back to front:
>
> + xid_age = TransactionIdIsNormal(relfrozenxid) ? relfrozenxid - recentXid : 0;
> + mxid_age = MultiXactIdIsValid(relminmxid) ? relminmxid - recentMulti : 0;

D'oh.

> 2) Would it be better to move all the code that sets the xid_score and
> mxid_score to under an "if (force_vacuum)"? Those two variables could
> be declared in there too.

Seems reasonable.

> 3) Could the following be refactored a bit so we only check the "relid
> != StatisticRelationId" condition once?

Yes. We can update the vacuum part to follow the same pattern, too.

> 4) Should these be TransactionIds?
>
> + uint32 xid_age;
> + uint32 mxid_age;

Probably.

> 5) Instead of:
>
> + double score = 0.0;
>
> Is it better to zero the score inside relation_needs_vacanalyze() so
> it works the same as the other output parameters?

My only concern about this is that some compilers might complain about
potentially-uninitialized uses. But we can still zero it in the function
regardless.

--
nathan

Attachment Content-Type Size
v5-0001-autovacuum-scheduling-improvements.patch text/plain 12.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2025-10-27 16:11:19 Re: display hot standby state in psql prompt
Previous Message Maxim Orlov 2025-10-27 15:54:35 Re: POC: make mxidoff 64 bits