Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w84nH-000Bkx-0B for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Apr 2026 23:16:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w84nF-002sTd-2u for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Apr 2026 23:16:14 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w84nF-002sTU-1Z for pgsql-hackers@lists.postgresql.org; Wed, 01 Apr 2026 23:16:14 +0000 Received: from mail-pj1-x1033.google.com ([2607:f8b0:4864:20::1033]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w84nD-000000005cI-45Yl for pgsql-hackers@lists.postgresql.org; Wed, 01 Apr 2026 23:16:13 +0000 Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-358d80f60ccso131045a91.3 for ; Wed, 01 Apr 2026 16:16:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775085371; cv=none; d=google.com; s=arc-20240605; b=Yg7KVJq/34Frudvg7DuXsdLu9kSiYKnkiTVOXWDV0K5fNxYLbbP68Nq+7k2T8LQRyw cINik/I8EGA7xQj9992nbE8pLek42+LDXjD8DIPIc7zRDpdaBRq3yR55iCuHneg7kPhu JmJ480IzP2phhRFnxapqqD2MDTndHSQz1jDF0hLf08O45lhJqnLDeZcbK8NiY0nCIing WnQOhLH6co55LfwYCZU2ugzACVGdnTiNJs2yadt6XJIQPPEdtw7bv1Xr5Awh+uqw10ce C+ORSwl3d3JAQ1NDH7ES9FytB5PHE+MGnGq0mIf8oJaIlel+abHMnMbOP2aKi8rS/zmo 4DQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=iO/jYDT1OzaS0AFIxFAxuWFXtZArT+qH+DUvieD7hIc=; fh=3FGWFoMqpUrhrRrQRzdDKEDNka9m4K+cWVe5IrQEPqI=; b=X+rL1p+zMdeAfFTXUhOtREh4PBjVR6ieg7q/88etc5hW2TmJtrrmGvPq/4NTeEe8er v82tz5giNZQxdYFBwGGuKKxr3AKGhINHylih+CC1qfGbai9kS/86DFyZse8pJ2DZbj0b GyVujNTrCkyJ3M6yutqMuVdNGodser2PwVAci/3QJ9mpQlRJPkTFsSXiM1P1l6tvqCTi xKct8A7yz46RHy8RrLj6F9XafiqImsH6C2LRHf5Vb/r2A1WjwBgRwuvG3SHxRwJgV0Zn B1GI+r8T0daXdMhHBAVey2hUof7jO/nUzHLXhLOdPcMGdc1lDROtbLwbe9toWsA/HH5V qUmg==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775085371; x=1775690171; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=iO/jYDT1OzaS0AFIxFAxuWFXtZArT+qH+DUvieD7hIc=; b=l7iAxY3Bgc3YwlLrSsgS69yWJGd63r9ysR8c3EvM1yN8WOu3/4hG7WX1kIv4GbSmPa tfKhq5zDi8lbgYvQm+olXDPU4SHOuZO4lZ4IatkeCJ2rJkp7cPCOH1LvSJe7hmZBHTOc MbedoyLkqJoEboF7Se2DSWi3A4aFdSkMCX/7nWNuJMPuL5EYQLzl9cXkJainiE7rNcw5 htvGq2usWrLVCVAKpjEdHgJ637ggTl7knKLmva7mTsPsiGlNKr3nH1nRpagV4i5vmP9z CrluoiI+I901tf9GI1QBg//cdrBY/Uuh8zID/W8PKMHRmHmtINoY68E4XVECGP8zm2q/ GyJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775085371; x=1775690171; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=iO/jYDT1OzaS0AFIxFAxuWFXtZArT+qH+DUvieD7hIc=; b=rfefHMyClRekgQ8jXJldHjVdf89hGW704QrUpNSLEIPiwClPXN6PI5R4rAgOhkIKIZ I/BWuPx0pHd4Vs4gYjEeheoSfXK7a/qmAaA6kDKjQJX17NxBtjNcQDjjoevRKnj/Ib17 mD7FNN2l/OXihpppQmGBsA68Fi6vUBW0jQ8bJhzSEMUYJE0PdJEIVePHLr4uqFNc1Cop NAsWYW08WywI35YIFkaF+Nvvzd0A6SBqa5AFKVo+OFOBV6mqgOMLwVrn6Ft8zQVSqKmb RwigNHdHWgGWDnTe8yPuRtORps7v9zjvLvAxklZlkaIQHyX5IPA0DUsmkDUGZiJ7y5hj 1vzQ== X-Forwarded-Encrypted: i=1; AJvYcCUtNj/T9L0LO3dFZqvoZbTKB3VFw4XLsb5eUdsduHabT1h5h8RO5HSR8WXpUStB+dO8sXKQ8ZPIp/zftAu0@lists.postgresql.org X-Gm-Message-State: AOJu0YxYB1IeUlI1g6Gj53vIa4K4sJ81CQWO4oDH6EZ2sNi1Azj9oQGO riY4SNN1UWoylnjbDnt+faCGizNiuoeOCNXDdmVKJkujytrvi64gmCch7WqhZn+ep86Pz10LsbR v+qzqi+zJGHmPycsvYysiQPPCm+hEhm8= X-Gm-Gg: ATEYQzw5H25vEukz2eeXxG/IPcLMOENc77irjmhxIAM9F3WnVBcP66ne9Wkch2GkR86 6lcCGWhCKnR0q6U+N37wYiRQvbch7lYL07K/UcOA0Fw0lbwma6GxTDExAOfW/bWeWQhWp9BP40K gDvzcBYFMGkO36Op3PWrR94oD7Eu5vemsZ9+zwTKWg2KKWJQ55a1PCqOOF4VUG4JYuxNpCCwVnn gUSNcmIhTjc5YqveaItHF+hBHsPCGTn19vLJ9T14Q5mhPXiNlzTX3GfeInMifhgs7h2KMVowtPB Kgugdlj0 X-Received: by 2002:a17:90b:3f4c:b0:35d:8ea1:62c3 with SMTP id 98e67ed59e1d1-35dc6e43b1dmr5394532a91.3.1775085371176; Wed, 01 Apr 2026 16:16:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Masahiko Sawada Date: Wed, 1 Apr 2026 16:15:33 -0700 X-Gm-Features: AQROBzD_Q1loIFNBiJa1J--BpCJV5-nnFxy0hRzuZb3juBXTkao45YeMsDCyotI Message-ID: Subject: Re: POC: Parallel processing of indexes in autovacuum To: Daniil Davydov <3danissimo@gmail.com> Cc: Alexander Korotkov , SATYANARAYANA NARLAPURAM , Bharath Rupireddy , Sami Imseih , Matheus Alcantara , Maxim Orlov , Postgres hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Apr 1, 2026 at 2:24=E2=80=AFPM Daniil Davydov <3danissimo@gmail.com= > wrote: > > Hi, > > On Wed, Apr 1, 2026 at 7:10=E2=80=AFPM Alexander Korotkov wrote: > > > > Thank you for your work on this subject! I've some notes about the pat= ch. > > > > Thank you very much for the review! > > > 1) The changes in guc.c allows autovacuum parallel leader to accept > > changes in not just cost-based GUCs, but any GUCs. That should be no > > problem, because parallel workers have their own copies of GUC > > variables, but I think this worth comment. > > OK, I will clarify it in the code. > > > 2) Maximum value for autovacuum_parallel_workers reloption is defined > > as literally 1024, while max value for autovacuum_max_parallel_workers > > is defined as MAX_PARALLEL_WORKER_LIMIT (also 1024). Should we define > > max value for reloption as MAX_PARALLEL_WORKER_LIMIT as well? > > I agree. > > > 3) Some paragraphs were moved from vacuum.sgml to maintenance.sgml. > > It particular it references > class=3D"parameter">integer > option syntax: (PARALLEL integer). Now it becoming unclear and needs > > to be revised. > > Good catch! You are right. > > > 4) I also think maintenance.sgml should mention the new reloption. > > Do you mean that we should mention it in the "parallel-vacuum" chapter? I= f so, > I think that we should also mention that max_parallel_maintenance_workers= can > affect the parallel degree of manual VACUUM command. Yes, we have already > written about this in the description of the PARALLEL option. But now the > "vacuum-parallel" chapter doesn't mention limiting by GUC for manual VACU= UM and > limiting by reloption for autovacuum. IMHO it is better to have redundanc= y than > an incomplete description. > > > 5) I think it worth having a test which check that setting > > autovacuum_parallel_workers to 0 disables the parallel autovacuum for > > given table. > > I see that VACUUM (PARALLEL) doesn't have such a test. Both manual VACUUM= and > autovacuum have similar logic with parallelism disabling. Is the increase= in > test completion time really worth checking these logic? I don't mind addi= ng a > new test, actually. Just want to make sure that this is necessary. > > > 6) Minor grammar issue in PVSharedCostParams comment, it must be > > "vacuum workers compare" (plural subject). > > Yep, I'll fix it. > > > Please, see an updated patch. Thank you for updating the patch! I found a bug in the following code: @@ -457,6 +534,9 @@ parallel_vacuum_end(ParallelVacuumState *pvs, IndexBulkDeleteResult **istats) DestroyParallelContext(pvs->pcxt); ExitParallelMode(); + if (AmAutoVacuumWorkerProcess()) + pv_shared_cost_params =3D NULL; + If an autovacuum worker raises an error during parallel vacuum, it doesn't pv_shared_cost_params. Then, if it doesn't use parallel vacuum on the next table to vacuum, it would end up with SEGV as it attempts to propagate the vacuum delay parameters. Regards, --=20 Masahiko Sawada Amazon Web Services: https://aws.amazon.com