Hi,
On Wed, Mar 25, 2026 at 3:43 PM Masahiko Sawada <[email protected]> wrote:
>
> Given that we have one and half weeks before the feature freeze, I
> think it's better to complete the project first before waiting for
> his/her comments next week. Even if we finish this feature with the
> opt-out style, we can hear more opinions on it and change the default
> behavior as the change would be privial. What do you think?
>
> I've squashed all patches except for the documentation patch as I
> assume you're working on it. The attached fixup patch contains several
> changes: using opt-out style, comment improvements, and fixing typos
> etc.
+1 for enabling this feature by default. When enough CPU is available,
vacuuming multiple indexes of a table in parallel in autovacuum
definitely speeds things up. This way we will also get field
experience using this feature.
Thank you for sending the latest patches. I quickly reviewed the v31
patches. Here are some comments.
1/ + {"autovacuum_parallel_workers", RELOPT_TYPE_INT,
I haven't looked at the whole thread, but do we all think we need this
as a relopt? IMHO, we can wait for field experience and introduce this
later. I'm having a hard time finding a use-case where one wants to
disable the indexes at the table level. If there was already an
agreement, I agree to commit to that decision.
2/ + /*
+ * If 'true' then we are running parallel autovacuum. Otherwise, we are
+ * running parallel maintenence VACUUM.
+ */
+ bool is_autovacuum;
+
The variable name looks a bit confusing. How about we rely on
AmAutoVacuumWorkerProcess() and avoid the bool in shared memory?
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
