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 1pZLgL-000439-VH for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Mar 2023 00:59:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pZLgK-0001eb-Gq for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Mar 2023 00:59:56 +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 1pZLgK-0001eR-4s for pgsql-hackers@lists.postgresql.org; Tue, 07 Mar 2023 00:59:56 +0000 Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pZLgH-0006Wc-Uv for pgsql-hackers@postgresql.org; Tue, 07 Mar 2023 00:59:55 +0000 Received: by mail-pj1-x1030.google.com with SMTP id x34so11723806pjj.0 for ; Mon, 06 Mar 2023 16:59:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678150793; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=tTPwYRqRjxtCkmk5bAvLKkIzIucQ76CeslXtoLs82Bs=; b=kosredt6CvajkBatQBDJztlcZN7EKk/d54f0eIDle3Mme0AZ7Iouk67iqiOwV0C10u /b2aFb/o8qkKudYibvUe7ahus6rvNgB4H5BHr+XXyDGB8SSsSE6m5NURp0kyxyPWDi8f FDE5I9A3N7L4Yizsd97QinwpaCM2uchrMwbsxL8mn0KEkYx8UT47fxGRo/t2Y3TJlxGR ibYFADXZlQuWYenxIQAeZHSUa/wp4SBbe9OHVgHXkwvQBHMhTcfkBqotWM/E+xuLb0ok xh3PsYaMaftyFzyx6nsrK0NjuWuNl2Vd8zF1dTT+qn444cSzZodF7rkayQDK2VNVt9so MM6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678150793; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=tTPwYRqRjxtCkmk5bAvLKkIzIucQ76CeslXtoLs82Bs=; b=sZWegyVlNyvqJg/CJNw5dUt5u9xbeXOAeNHgoh+0v0vpDNLjfpGc2sgMMTpmoh6H8C OgWVDfyppWN5RuFdqt46gHa1YQYQMMLf2BklbKymZFVxAofgFwWG1KvqXmNbH6DOnyVw 8hju0637P0Wm+LxGx6rD+QExo1vYuViNeCh08dBhgR5j/U8Z8qsNWrZ27Z4RYA6qSton IdB+WsGVcvXmYupQWqyJh5MafBWy2TSwBwaNfcgDaId4W7EqESQEniu2r3lOiODLEi/L jmPTmuhU/cclijLWROTGxOHiyWakBMIFOiz0i+o4PV5VW549FgmljvTo0B/5q7yCcSQy Qg5g== X-Gm-Message-State: AO0yUKVK88hi1kWYM4LoOz0aqVOV7DyyJ9jCIwChM+LqWqRQh8EF+KkE pSRNvczDcvWZXMRZBl3V7v8= X-Google-Smtp-Source: AK7set9nROqqIMAUOQD0zEGcuTscnw8Avoq976lm7ImtH23s1Odk4CKe1/H8mhm1SxoCpMWgM8U7gw== X-Received: by 2002:a05:6a20:4b21:b0:cc:24de:6a72 with SMTP id fp33-20020a056a204b2100b000cc24de6a72mr10902322pzb.61.1678150792807; Mon, 06 Mar 2023 16:59:52 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id h15-20020a62b40f000000b005a8b4dcd213sm6834127pfn.78.2023.03.06.16.59.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Mar 2023 16:59:52 -0800 (PST) Date: Mon, 6 Mar 2023 16:59:49 -0800 From: Nathan Bossart To: Michael Paquier Cc: Melanie Plageman , pgsql-hackers@postgresql.org Subject: Re: add PROCESS_MAIN to VACUUM Message-ID: <20230307005949.GA3266981@nathanxps13> References: <20230306173723.GA2934573@nathanxps13> <20230306194009.5cn6sp3wjotd36nu@liskov> <20230306202734.GA3033389@nathanxps13> <20230306211337.GA3076909@nathanxps13> <20230306220958.rk4b4msmybi6hm56@liskov> <20230306224310.GA3165453@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Mar 07, 2023 at 09:20:12AM +0900, Michael Paquier wrote: > - * Do the actual work --- either FULL or "lazy" vacuum > + * If PROCESS_MAIN is set (the default), it's time to vacuum the main > + * relation. Otherwise, we can skip this part. If required, we'll process > + * the TOAST table later. > > Should we mention that this part could be used for a toast table once > we've already looped once through vacuum_rel() when toast_relid was > set? VACOPT_PROCESS_MAIN is enforced a few lines down the road, > still.. That did cross my mind, but I was worried that trying to explain all that here could cause confusion. If PROCESS_MAIN is set (the default), it's time to vacuum the main relation. Otherwise, we can skip this part. If processing the TOAST table is required (e.g., PROCESS_TOAST is set), we'll force PROCESS_MAIN to be set when we recurse to the TOAST table so that it gets processed here. How does that sound? -- Nathan Bossart Amazon Web Services: https://aws.amazon.com