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.94.2) (envelope-from ) id 1rLX5e-008UiS-63 for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Jan 2024 23:25:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rLX5c-00G78j-Sc for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Jan 2024 23:25:28 +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.94.2) (envelope-from ) id 1rLX5c-00G78b-Fl for pgsql-hackers@lists.postgresql.org; Thu, 04 Jan 2024 23:25:28 +0000 Received: from mail-ot1-x335.google.com ([2607:f8b0:4864:20::335]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rLX5Z-00DliI-I6 for pgsql-hackers@postgresql.org; Thu, 04 Jan 2024 23:25:26 +0000 Received: by mail-ot1-x335.google.com with SMTP id 46e09a7af769-6dbcc5d78eeso575385a34.3 for ; Thu, 04 Jan 2024 15:25:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704410725; x=1705015525; darn=postgresql.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=hsnKQHcLr4/GU2h/NCZVrwWpRtnf0EDn+CG3p52+n1M=; b=KM0QMp36Gw+klkjKzH4yRWhm3nBspVlQThsWiPgJwSGhTtMwR3CGBqsGtiNhU8aI6f /w8DZB6deTT2wPsL3tuV6JMYfJE/1NJiCcQIKONxyJwytR6HRMIlFMEodvpUuoiSLylj 5G9BtwiKZcH8XgKrexStavtHTHSAxY13Dmyhi6tt+f5R/D31wcdF9gBiAZzHBnWJks68 KqlYE1fjUFhsf54Uxcpb+1AcSg3OklGoX6hQSDz/+Fonw5ZUef40UkZBey4UwIsLNGJr 4sJXtX4ETSVnOtg/oFN6vKSDNXh6aqPMHIbAfZkv0PlXape5BwkWkTTQMYaE0B6xaSei 8znw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704410725; x=1705015525; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hsnKQHcLr4/GU2h/NCZVrwWpRtnf0EDn+CG3p52+n1M=; b=fp506fIdZfLfc5gpRYxvUflH6TOBpTbZF4LSApoQzofTYIaQyZjf45XDQgbPSW3vKp g/WrU12YlrB47i+ls8qlXJzN5aFVWbLkwA+aZF+QSSOX3uVhxawJAC6yaty+6ji1yJMJ z6219c6gJ58DBtnik4C/Fw4lff8BDfM73wgRCrpZEQb7zF/qtS0b5UvC4XJrPkro2NBc QEvgllTRg1YdkWp1aiOSSUyEQQKBzGRSsEM1oBUWFXtEYXtxvlOVog0Vf20uU3ppF5RX yFtvksSn7l4A8u+uUId1JwnNRr7ltZ/xUv4b2GaTbBjQewkVf0K6AYtZZZ+Cp2FBLXqg x8EQ== X-Gm-Message-State: AOJu0YyB5XP70Rf/bGuCiJojp9ihIGxYctAhYCB+zVM6jX+dpju6OM83 nkH6NUyiuzBgPX3XWo0cALHlnXwo88nN X-Google-Smtp-Source: AGHT+IHrVQ2CRL226OE0h0rWzy49Z103VbNB1sqa+Tv4c31nkJxSUrqqQd6gwkMF4EDTeR9V5WOXCw== X-Received: by 2002:a9d:6f01:0:b0:6da:32cd:893d with SMTP id n1-20020a9d6f01000000b006da32cd893dmr1479597otq.50.1704410724860; Thu, 04 Jan 2024 15:25:24 -0800 (PST) Received: from [192.168.2.23] (070-113-014-216.res.spectrum.com. [70.113.14.216]) by smtp.gmail.com with ESMTPSA id e20-20020a0568301e5400b006dc4c57dd0dsm90846otj.79.2024.01.04.15.25.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Jan 2024 15:25:24 -0800 (PST) Message-ID: Date: Thu, 4 Jan 2024 17:25:22 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Confine vacuum skip logic to lazy_scan_skip Content-Language: en-US To: Andres Freund , Melanie Plageman Cc: Pg Hackers , Heikki Linnakangas , Thomas Munro , Nazir Bilal Yavuz References: <20240104202309.77h5llrambkl5a3m@awork3.anarazel.de> From: Jim Nasby In-Reply-To: <20240104202309.77h5llrambkl5a3m@awork3.anarazel.de> Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk
On 1/4/24 2:23 PM, Andres Freund wrote:
On 2024-01-02 12:36:18 -0500, Melanie Plageman wrote:

Subject: [PATCH v2 1/6] lazy_scan_skip remove unnecessary local var rel_pages
Subject: [PATCH v2 2/6] lazy_scan_skip remove unneeded local var
 nskippable_blocks

I think these may lead to worse code - the compiler has to reload
vacrel->rel_pages/next_unskippable_block for every loop iteration, because it
can't guarantee that they're not changed within one of the external functions
called in the loop body.

Admittedly I'm not up to speed on recent vacuum changes, but I have to wonder if the concept of skipping should go away in the context of vector IO? Instead of thinking about "we can skip this range of blocks", why not maintain a list of "here's the next X number of blocks that we need to vacuum"?

-- 
Jim Nasby, Data Architect, Austin TX