Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pWvAN-0000Ng-Tq for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Feb 2023 08:16:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pWvAL-0001O2-UN for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Feb 2023 08:16:53 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pWvAL-0001HU-IE for pgsql-hackers@lists.postgresql.org; Tue, 28 Feb 2023 08:16:53 +0000 Received: from mail-lj1-x22d.google.com ([2a00:1450:4864:20::22d]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pWvAE-0006Ky-PH for pgsql-hackers@postgresql.org; Tue, 28 Feb 2023 08:16:52 +0000 Received: by mail-lj1-x22d.google.com with SMTP id j17so9224307ljq.11 for ; Tue, 28 Feb 2023 00:16:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677572204; 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=j21ge3RCZ5CjE5Tv5MmBHySp/0qeB0Cq5uc7crcMzJU=; b=oNSpHwZs3flE+ePQo4JmpC0hbzMkE6u5+gJKUonhrbAhOWsVL3ubA0X7pLnpqwmywk JKVQCKgiFXKNDF2iorB4TmyynPZCF0r/g2gMJ6OxevMERLjUfVgMB9TYoBTlyPRnM1j7 SJqxAMDbH1DsfblgJL9u3Sw0f5anw1Je3GT42DOJ1JYoxamAegWPE11LHVzpIz97NRFi jQC4d79ChpD3HjbEVCRjRAiWBEqF8jLrKPZ8TFsiEZ8oPLL74Smysyk+hiaHSvUX00Z0 8UQ1Cg5zbOEFwL+PxQAJUsUNiVHebWEirnsyroRJWGIRRj9uH0SseEtDLWfuWkxBYlPh Wq/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677572204; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=j21ge3RCZ5CjE5Tv5MmBHySp/0qeB0Cq5uc7crcMzJU=; b=d9T82QHtrE/8HRBn/SWbX7CGklxMK9NAZhgrKATab2I3U+bn9eEhyn2AjUkur+ZoPu e4nj2KzkP/+GwgQs5pq34Bm5/gZ2+2vAmXzozw/d5W4HMvRgztIggaomk9GTo2hUAMcm uhb5p3fjdGPswLFChW9WEc+7yCHWI3bfy4jdFbCJmwNQFGxJhh9IAu8sCJ9KzO3k2Tp1 XNN7LQL2bJ7ZGexcPCrIAqyKjazrrT4hvp1PXlP+tWvZzWdxgBMFyshHfBAtXzQMkwjU eCyOO8ZAcsfTdoE4OnksVnM+F37tZe4f6jwstBzSkwPCd4TUoZRUFHXp+kNcZM2oVbR2 wLxA== X-Gm-Message-State: AO0yUKWEdfVJzU41stg/tkdsycL0v0cHx9h+u4n9a0IN6D1tuPw+rOI0 P71dU+mzIL+fGJ+PYKjvzEMl62Si2SKPXDzwQZw= X-Google-Smtp-Source: AK7set9GYdnCd8EVtdvtlmnjhp1V82GiJzNfPyxhpqKf9LM0+I0cTwN+j46IlUis28kephDUbUuotrmh2ttuwLegYJ8= X-Received: by 2002:a05:651c:1614:b0:293:27a9:ef34 with SMTP id f20-20020a05651c161400b0029327a9ef34mr4880377ljq.0.1677572203860; Tue, 28 Feb 2023 00:16:43 -0800 (PST) MIME-Version: 1.0 References: <20230111182720.ejifsclfwymw2reb@awork3.anarazel.de> <20230111185854.5srlvequbxbg5p6c@awork3.anarazel.de> <20230111191842.5ywh7twkis42kxad@awork3.anarazel.de> <669645.1673471914@sss.pgh.pa.us> <20230111213905.4ljixbm2oyqzvzzx@awork3.anarazel.de> <20230112003638.bdigosdroqn7vp5h@awork3.anarazel.de> In-Reply-To: <20230112003638.bdigosdroqn7vp5h@awork3.anarazel.de> From: Bharath Rupireddy Date: Tue, 28 Feb 2023 13:46:32 +0530 Message-ID: Subject: Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode To: Andres Freund Cc: "David G. Johnston" , Tom Lane , Peter Geoghegan , pgsql-hackers@postgresql.org, Robert Haas , Melanie Plageman , David Rowley 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 Thu, Jan 12, 2023 at 6:06=E2=80=AFAM Andres Freund = wrote: > > On 2023-01-11 17:26:19 -0700, David G. Johnston wrote: > > Should we just add "ring_buffers" to the existing "shared_buffers" and > > "temp_buffers" settings? > > The different types of ring buffers have different sizes, for good reason= s. So > I don't see that working well. I also think it'd be more often useful to > control this on a statement basis - if you have a parallel import tool th= at > starts NCPU COPYs you'd want a smaller buffer than a single threaded COPY= . Of > course each session can change the ring buffer settings, but still. How about having GUCs for each ring buffer (bulk_read_ring_buffers, bulk_write_ring_buffers, vacuum_ring_buffers - ah, 3 more new GUCs)? These options can help especially when statement level controls aren't easy to add (COPY, CREATE TABLE AS/CTAS, REFRESH MAT VIEW/RMV)? If needed users can also set them at the system level. For instance, one can set bulk_write_ring_buffers to other than 16MB or -1 to disable the ring buffer to use shared_buffers and run a bunch of bulk write queries. Although I'm not quite opposing the idea of statement level controls (like the VACUUM one proposed here), it is better to make these ring buffer sizes configurable across the system to help with the other similar cases e.g., a CTAS or RMV can help subsequent reads from shared buffers if ring buffer is skipped. Thoughts? --=20 Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com