Re: POC: Parallel processing of indexes in autovacuum

From: wenhui qiu <qiuwenhuifx(at)gmail(dot)com>
To: Maxim Orlov <orlovmg(at)gmail(dot)com>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: POC: Parallel processing of indexes in autovacuum
Date: 2025-04-17 03:16:29
Message-ID: CAGjGUAKbUEuF1_bKzBa1vT-Le4WeEPKNs3h6xCojcXBmPEZkGg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

HI *Maxim Orlov*
Thank you for your working on this ,I like your idea ,but I have a
suggestion ,autovacuum_max_workers is not need change requires restart , I
think those guc are can like
autovacuum_max_workers
+#max_parallel_index_autovac_workers = 0 # this feature disabled by default
+ # (change requires restart)
+#autovac_idx_parallel_min_rows = 0
+ # (change requires restart)
+#autovac_idx_parallel_min_indexes = 2
+ # (change requires restart)

Thanks

On Wed, Apr 16, 2025 at 7:05 PM Maxim Orlov <orlovmg(at)gmail(dot)com> wrote:

> Hi!
>
> The VACUUM command can be executed with the parallel option. As
> documentation states, it will perform index vacuum and index cleanup
> phases of VACUUM in parallel using *integer* background workers. But such
> an interesting feature is not used for an autovacuum. After a quick look
> at the source codes, it became clear to me that when the parallel option
> was added, the corresponding option for autovacuum wasn't implemented, although
> there are no clear obstacles to this.
>
> Actually, one of our customers step into a problem with autovacuum on a
> table with many indexes and relatively long transactions. Of course, long
> transactions are an ultimate evil and the problem can be solved by calling
> running vacuum and a cron task, but, I think, we can do better.
>
> Anyhow, what about adding parallel option for an autovacuum? Here is a
> POC patch for proposed functionality. For the sake of simplicity's, several
> GUC's have been added. It would be good to think through the parallel
> launch condition without them.
>
> As always, any thoughts and opinions are very welcome!
>
> --
> Best regards,
> Maxim Orlov.
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2025-04-17 03:42:22 Re: Skipping schema changes in publication
Previous Message Tristan Partin 2025-04-17 01:57:26 Decouple C++ support in Meson's PGXS from LLVM enablement