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 1wA6Xw-0024An-0U for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Apr 2026 13:32:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wA6Xu-0005vo-1u for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Apr 2026 13:32:47 +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 <3danissimo@gmail.com>) id 1wA6Xu-0005vf-0Z for pgsql-hackers@lists.postgresql.org; Tue, 07 Apr 2026 13:32:46 +0000 Received: from mail-yw1-x112d.google.com ([2607:f8b0:4864:20::112d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from <3danissimo@gmail.com>) id 1wA6Xs-000000012Tg-2pow for pgsql-hackers@lists.postgresql.org; Tue, 07 Apr 2026 13:32:45 +0000 Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-79827d28fc4so42257367b3.1 for ; Tue, 07 Apr 2026 06:32:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775568764; cv=none; d=google.com; s=arc-20240605; b=Zr+1poXcOi2ah3AAw07NFO+tBimvCk3kj1ILdJip2eWKlCIlhD8VC3gsIr9QaN+Rzv kiq8Z4WYaZSKHgYG0NtifDjbq/Q8pwir5Rj3Eo7esQu9CjYW80307WOYS6YfnYWObRai pkbdOIGZauG46BsVdET8pCCi6lrs86vMkN6gcS+3nYAZhQMY2kkF7fYZxfOxdJNiNwkW T2zDySOnanJFK0Dih4LD7gLsufdWFzJbTw2c9mQhjDSgN+QnKsh7gv+MotGUESKCgPq5 kUFR6z4NGVmkAf1bJNVAAZt1URfyYl4ZKRopkk5y1rYOnrEnGn6eDtWkv2XSHp62q0Mp SKTQ== 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=W+E1eQ7hC7ENzfzLHRDBCoVDbdtT6vDIzxUX8BIJKgg=; fh=G1z+Dfs+aIwNYfpwb/SaSi/TeTjItTiQTt1VkofqadA=; b=Nia/zNHZqULSqDD7gF5kNBmWLb8b7qqk0r+NUU4m16syw2UobgrmAfiaYpCinVgKlh w/V4/6dR4Nnu4z77vliYmV4uhPhSGhh8h1e0HnIDa3K0aO53LoyTycotYyHxkfTTsJPg IwowWKmbMOhSgnKM7xyaY+ahtyVzx65Lu9wqtgBpNN3s5LYXFVlgkACihRJGpW0zpV6G kjPRlsZ50zH7mspB8e/AHOJxWzEWsVNoJIhylLoKHOsbN/KyO5PXDTGl2pLlh1swCfNy UWncqMDW6v7z39tF9DNh0WqLrszky/eVOLTG6r5c+BDVs/TeSXhh53UBP3rApFHeZd25 ROSw==; 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=1775568764; x=1776173564; 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=W+E1eQ7hC7ENzfzLHRDBCoVDbdtT6vDIzxUX8BIJKgg=; b=NbwC0GSsNAe+JbpGbXJ4UtXSqyxhzBo4h+HHdY90eOguw/R1yhODbGodzfIwtIsrMe Uis929YEdx0OVxvDcXdIVFnb/qb/9sdT3d9356fcoYueQwXLlKID0bXjMAo7yPZNPbKd RXUqgkHdAv/Xa7Uwl1JFf9G0dNuJi36inMVmsiohjVNOspOxuwNyzO8C1+w6iNkAqY8y MjcIcAc1jubRixDAQXvLhMF5GAxI3RR/wnvW8eo/hzraCLP812c0t7vD8kYlSxkxTlZk hlHaWzBPU32KENu4mLNMWh8Hel6Ee+zANU6JhKWI49tJfJvhxL30Xu8s3KQOAHJWpyfl ot/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775568764; x=1776173564; 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=W+E1eQ7hC7ENzfzLHRDBCoVDbdtT6vDIzxUX8BIJKgg=; b=UGEzNQI1cvlhjTxAsZfb9um/19GC/F6FGPZGmWwcv5U3WIYnlIQEBddsdlac3OgAW8 +WYI1mnY43A+cHkj0d2rDIArENoHaK1ZiwmW8euj0KP7fxip//y9CiC1mhWQgYNW9SEh y+rR31Z5QH3Wc/aVkEc9ZQPEEGcY4S5a3MWYZkcLNkia+YwjrkjZI33pXJAwrducVTn5 JbIQlMxdrDudSpqQwzFQDb2HUkkdoRYVg9zTGpC9siDRR7WgY4daUOGz9pxifIuUA0cK HqfpkC3gtpwCe5DE+ymL/R+Uks+Un9uNDmevFWwG+EI1C/zknhAD8K5hatYY/nS0dMfQ kJAw== X-Forwarded-Encrypted: i=1; AJvYcCV99Xvox2kXkG/Bxk24+8e2k4ElNt1v+xC76YHGA7rsSPjYEy/l0WLYZi6vg9GoTjIfqM7tAyb5nQ5K/r1J@lists.postgresql.org X-Gm-Message-State: AOJu0Yz0WbezeuKL4SLEvYPV/TkRWP/5/kX7yxF0BMv40ETYSZC0VKDZ Z3OiL1nRonRDK095ODg33Fe+vlmPmUSKbWn/ZyRDCLge8WcO+MLzaAvT1iDBOxmCvRVqXLObh9Z 5klwkCDZ/pEicAktKfGT08Ty/bW20JE4= X-Gm-Gg: AeBDieuHeUTjbosbmUHPOl++1WVOI4/LsE0AzI6rVBxHnaDwjl4S6YIac8+pqh/Dk1F aPa0+JiorR+aM9bzDXCp6YKSfMkH+0xDuRZ5VfUQylIegUyDe5v5vEp512SHrMSzBUonsCG5tkJ QmSuMMx5ZAcMg+A8XcJNIXYrTbxHPv8/f6el3a7jrLWTpTjlAA31S3NxTgfWTNMgL23SLDy6hIV Y4bEWtuEahqZHiWh+JgOZhS2Ac7ebAxE7pb6lNUCM69avORycT3kXBF1a6U/L7s1p0wwa/JLB/J KpPbpUDB X-Received: by 2002:a05:690c:f15:b0:79a:c40d:b701 with SMTP id 00721157ae682-7a4d6933f05mr173254747b3.13.1775568763939; Tue, 07 Apr 2026 06:32:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniil Davydov <3danissimo@gmail.com> Date: Tue, 7 Apr 2026 20:32:32 +0700 X-Gm-Features: AQROBzAr34wYgHW4HmITl60y_OD7rMPp2wRd6Efm-WihsGPAoTY3N0Iy-jM6yzk Message-ID: Subject: Re: POC: Parallel processing of indexes in autovacuum To: Masahiko Sawada 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 Hi, On Tue, Apr 7, 2026 at 10:49=E2=80=AFAM Masahiko Sawada wrote: > > > > > > > While some autovacuum parameters do override GUCs, those are typicall= y > > > local to the process (like cost delay). Parallel workers, however, ar= e > > > a shared system-wide resource. In a multi-tenant environment, allowin= g > > > a single table's reloption to bypass the > > > autovacuum_max_parallel_workers =3D 0 limit could lead to unexpected > > > exhaustion of the worker pool. > > > > Will this exhaustion really be unexpected? If we describe such an abili= ty in > > the documentation, and the user uses it, then everything is fair. Even = if > > administrator forgets that he enabled av_parallel_workers reloption som= ewhere, > > then he can : > > How can DBAs prevent parallel workers from being exhaustly used if > users set a high value to the reloption? > Only manual control. Since DBA increased reloption manually, it is OK to as= k him to manually decrease it. > > 1) > > Check the logfile (if log level is not too high) searching for logs lik= e > > "parallel workers: index vacuum: N planned, N launched in total". > > 2) > > Run a query that selects all tables which have av_parallel_workers > 0. > > Does that mean DBAs would need to run these queries periodically? Not really. I say that even if DBA has lost control on the parallel a/v workers, it has an ability to find these bottlenecks. > I don't think that in a multi-tenant environment, DBAs can (or should) > execute ALTER TABLE on user-owned tables just to fix resource issues. > Well, the people I talked to had a different opinion which is based on clie= nts feedback : what is acceptable and what is not. I don't think that we can convince each other, so let it be as it is :) But if you don't mind continuing to discuss this topic (perhaps with the involvement of other people), I would love to create a new thread for it. > > I guess that the question is : "Is it normal if the GUC parameter will = lose > > ability to turn off parallel a/v everywhere after the user has manually= raised > > the value for the av_parallel_workers reloption on a few tables?". If t= he > > answer is "Yes", I don't see any obstacles for us to allow overriding t= he GUC > > parameter via reloption. > > I think the answer is no, particularly for this parameter. Since it > controls a system-wide shared resource, it should be capped by a GUC > to ensure centralized management, consistent with other > parallel-query-related GUCs and reloptions. OK. I believe that "global switch" will also be pretty handy for many use c= ases. > Thank you! Pushed. Great news! Thank you very much for your help, Masahiko-san! -- Best regards, Daniil Davydov