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 1w8cwH-000inm-1Y for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Apr 2026 11:43:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w8cwG-00BUFu-0y for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Apr 2026 11:43:48 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) 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 1w8cwF-00BUFm-3D for pgsql-hackers@lists.postgresql.org; Fri, 03 Apr 2026 11:43:48 +0000 Received: from mail-yw1-x1135.google.com ([2607:f8b0:4864:20::1135]) by magus.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 1w8cwD-00000000MkD-3WlN for pgsql-hackers@lists.postgresql.org; Fri, 03 Apr 2026 11:43:47 +0000 Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-7982c3b7da9so16490797b3.1 for ; Fri, 03 Apr 2026 04:43:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775216624; cv=none; d=google.com; s=arc-20240605; b=S0hAW6KRumw9VSdJAWmlS+MujRqD0XhewdQIIKDLPvwnIZ7PzjJb/Zb/iNjiqTYE4+ TYtbjlDER697+9pbXmwhgo9da9kNRPIhzFWcygx4YklaxXdT/bQ5oXHwj/Je5dkTNc7x DP6LWCWcrkdkpb14CZCtVHCX2FSHzFR1VZHx4IylGk0eUrPF/HxjLYtokzT/QDylt2cx 2G1KTAfbY54vjuQKKv5GOK9MrpFMXjxfk5aivqCkjDXlB5joizDffukgbJJ8b2BrZb12 qhKabeJ6RF1T+qKmBV1w+tG8at2CDZCmInEwI87ZXhImeJGJ0WCwAOts/Ft5GchL6/Qe XHvQ== 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=B1vsSIH5xpHEyNADR6NXqdotC2hcIySiBDbWAwjnWPg=; fh=fwPskAzPQbBEO2wNBkph8w9hMDAIj1IdbOCVZ0JZzhA=; b=MddOtg0WP6bHfUkJRK0v0RjzqIeXkgtd6TGjYHqI1Idrf6qa0z8Ky1Y4Giw+QaO6yi KMsXXyhbcl0pD0rBA6kcDRVHf+TxIohad4wdkbzuWBdk+E3YQRZ8DVH4CodVx/HHlNb4 TMf7rDVLfySxQUReDKxYSFCx4rNxewGHI1SM+SL14X2YNn+/hmkvSZC4XyXIutLcsdFg uqdmWd/Sgrq2xp/c9ygA/AS18F34OYyLyN6t6x0In73lApD7QBcV+jCUZDApDMfi+TIL JhXW5gm+lhJ6Vkljc5hUD/EqYjLrTVr1fNR5Zjir2mYCB6RjjbdovcmObTud884RGM4j MTdw==; 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=1775216624; x=1775821424; 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=B1vsSIH5xpHEyNADR6NXqdotC2hcIySiBDbWAwjnWPg=; b=lTP3JrOYxX7OZfgbh6k3Ht6UIV2dJz1wXjFF8b9yRBG4tvIQIrvniGFM/E33hJCcQs OR43rUUPPJ+n0EdKL9V6+lGMzs0o9fkKEtfPr75upi5w3SPIBqmnU/kNX4m773QXcIub n/9obW3LpiRflWi9KCdPQzSjytLof4pF3kGz+C/wXq8Y8p2q7+8fy6FcslFPKpilSVOM fniImq2F8cOM6ovtfMlIUBHv4fTQ2eVKdEOXG66XfCVxuROYmIJcHtmYjiGtoUGV0eoK BSZ/xp3kChh0GylRks+FmFIhoMMfJD3A/Idw8mMa7r+zSnhmf63k0G4UdrdyY/OcopO6 Zp0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775216624; x=1775821424; 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=B1vsSIH5xpHEyNADR6NXqdotC2hcIySiBDbWAwjnWPg=; b=fqpBPLKECrNuGWeI6qEuTTZzB2w4JJHfYiigEL2QSQk6AmlmtSu9htX0ivP0BpshRl YqA1oRt32zYTH0xuP7sIbLwAfJkRWMM599aN2mT/1WGJ2a0TMZsaB15t6DDUEliFiqu/ d02Yc4/JDV7qNjvNDOClc1CLcRgn6XNwxD3a0BLbKzym3QwwJpJ4C91CPhROS2xUi8CC HduO2yuKR8Ajje77kW+dCp0YPbNo7ceWJ9bkV+KmhcMbIYT0RvPBRCBtrKnENmse2jse 9mEvG5s5Un3ef3kSIgkpZSy0xXMCXIXaJ1qg15YYl0gFAQiM4PB8uudnl7Nj7yp9Nrwd OvQQ== X-Forwarded-Encrypted: i=1; AJvYcCWz+hBDl7EIFhfTJFVCInsDzKs6MKriafC8KRGjat3HgkS7gJ5M6wPuZ+WZgN39AQoWp+nEj/WaKfuBDd7h@lists.postgresql.org X-Gm-Message-State: AOJu0YzGC4U071+f2/cyNOh4oh0lUXMzXChPzfE5hgyOunhhavnRdEpf TnxLtSh3VeSUa9BcTBw+v75KnBeyqkqK9zRikbtoyNLQgSgP5kaEW6aFb61K1sbOE99Vab2kRdD 5CznV7NiiulhOvJ07Z3ScHTJ/vD2cek4= X-Gm-Gg: AeBDieveHGMqZlqhLag5wHJsGN4K0uaNmaf0UHSimn9V+gsPTNEs5OkKwhm68An4yfH Y7kv52u9WqZIplWBAOC2TcBQoElEplIhr5VbqzglZlvfiCtbJIaVN3o1s4PQEC9pGBoapg4nb6o VJU3wLphLiKj8lEgA66GsBCDb7sYGrP0szmIHP7Z85JvFuvwzkIPWklnPxw+VJR0DTdD4uheMQI mb+lqQ1GJcZm8L0w3jsvW3t7hB+1UuYS9gKQW/qX46XbIGcE3IDCCq1d3Fmckg0nf8jt8ySqk7h 4utfHuUG X-Received: by 2002:a05:690c:81:b0:79c:c51c:7f57 with SMTP id 00721157ae682-7a4d536b559mr28110707b3.27.1775216624083; Fri, 03 Apr 2026 04:43:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniil Davydov <3danissimo@gmail.com> Date: Fri, 3 Apr 2026 18:43:33 +0700 X-Gm-Features: AQROBzC8MmN7sZQTjeeW3iqYhBGGP5HlcYB6nnHsPPzfYwPM3OIIktjHmnWAGr0 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 Fri, Apr 3, 2026 at 6:31=E2=80=AFAM Masahiko Sawada wrote: > > What do you think about the idea of using proc signals like the patch > I've sent recently[1]? With that approach, workers have to check the > local variable. It seems slightly cheaper and can use the existing > logic. > Thank you for the patch! 1) Maybe we should implement this logic within ParallelMessages? For exampl= e, I see this ParallelMessages use case in parallel a/v : /* * Call the parallel variant of pgstat_progress_incr_param so workers can * report progress of index vacuum to the leader. */ pgstat_progress_parallel_incr_param(PROGRESS_VACUUM_INDEXES_PROCESSED, 1); I.e. parallel a/v workers already communicate with a leader via ParallelMessages, so it will be convenient to extend this protocol by a new message. 2) I don't think that the difference between accessing atomic and local variable can be measured for parallel workers. But sending a signal to ever= y parallel worker is surely slower than just incrementing an atomic variable. IIUC you created this patch in order to solve the task of using an existing infrastructure instead of creating a new utilitarian solution. However, I t= hink that both the polling approach and signalling approach (in its current implementation) are basically equal. I mean that in both cases we have an autovacuum-specific mechanism to share particular parameters between partic= ular workers. I will try to explain how I see the solution to this problem. : Your implementation can be made more abstract, so that it becomes a new internal mechanism that other modules can use in the future. E.g. we can cr= eate an interface that allows any parallel leader (not necessarily just an autovacuum leader) to inform its parallel workers that some config paramete= rs have been changed. At the same time, parallel workers can use this interfac= e in order to specify, which parameters (or groups of parameters) they want to consume from the leader. What do you think? -- Best regards, Daniil Davydov