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 1mRM1j-0001t9-4S for pgsql-docs@arkaria.postgresql.org; Fri, 17 Sep 2021 22:08:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mRM1h-0005DI-Tr for pgsql-docs@arkaria.postgresql.org; Fri, 17 Sep 2021 22:08:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mRM1h-0005D5-JS for pgsql-docs@lists.postgresql.org; Fri, 17 Sep 2021 22:08:09 +0000 Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mRM1e-0003Fo-Ew for pgsql-docs@lists.postgresql.org; Fri, 17 Sep 2021 22:08:08 +0000 Received: by mail-wm1-x32f.google.com with SMTP id l18-20020a05600c4f1200b002f8cf606262so11013568wmq.1 for ; Fri, 17 Sep 2021 15:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=Sxbuz9cHtoEtT6l/xPARBVwqeWtw/oDvDK/dQ2Y9RzU=; b=CMpvmogn6Dg41UGDYWAiOpYDNP+4+7ZvOfpLRDpuT0NS+a3rGo/ovUTi0kFEJRRTC/ h42pdt6h72eiUtToCv58czDQluV0CScL4k5Ju4nRkTnZFw9FpZxLwvmL/79gBrqBv8Un pBB3Bqe5j4G5O9PXp29VfTVSWVaDEi+HIAxCxitrR/3ABioXWUeYhJzljMYD4LDFO3L7 YZZT2oatNSYMHCeHmDUx6k9g4gjkboQGXmgDEhs8guRp8INVEfyGC2LvzfHIbhrlYybo byAdC0OB0PTzv5suKUAXW50JnJGI/AY20XX2Q2wsWbEnhJqcUXAOzr+rtzd2YP28+5UV pYOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=Sxbuz9cHtoEtT6l/xPARBVwqeWtw/oDvDK/dQ2Y9RzU=; b=6sAALBQBOMy6TIP/YvU8nia63xZxROzupkMY04O8rTTMbHX1kvXrDdEMOSeFoj8ctO 3DE1RW8RNLi1QcYYolWvn1It4ORGJO30NYVEw8fKVRhV9TCUqak3R7i7mgedf38GgOgI rQKlrVIoc/Ytx0hD+jk53wb9UYhTYKQoWM/fd/rr1xZXDfm/mXbm8YoKFkfIOqbJ4OKN fo3nxj6p86G4kM4zYwx4bdIizEPZU/Wo6WFY+0ds21DzJGhdnF0EfLJ4sEYeX7zyRBYX CP1scH2XmVZgwoBeKW2gTANoWYBwG8uAgpNdZxjwzAfe/mLKHp93Y/EaWWUO9YwYKdhY 10NQ== X-Gm-Message-State: AOAM531KHoB2B2av+8jjmVJXrktm7wQbFd908sLYdYMsekB/o5a+Bzje 1Cxf39el3LPXSAlm/LqGoj7twA== X-Google-Smtp-Source: ABdhPJwWVaDV0Fdcm5Tm4+bmBWx4Jqn3uh6/322QzqkEhrIo/dDVOMyk1BJUr82VA70vn1G6agBF5Q== X-Received: by 2002:a1c:3584:: with SMTP id c126mr12959972wma.0.1631916484426; Fri, 17 Sep 2021 15:08:04 -0700 (PDT) Received: from localhost.localdomain (178-190-170-15.adsl.highway.telekom.at. [178.190.170.15]) by smtp.gmail.com with ESMTPSA id p1sm7475919wmi.30.2021.09.17.15.08.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Sep 2021 15:08:04 -0700 (PDT) Message-ID: Subject: Re: vacuum_freeze_min_age description validity From: Laurenz Albe To: sanjaya.waruna@gmail.com, pgsql-docs@lists.postgresql.org Date: Sat, 18 Sep 2021 00:08:03 +0200 In-Reply-To: <163186886974.4680.11795770889268302099@wrigleys.postgresql.org> References: <163186886974.4680.11795770889268302099@wrigleys.postgresql.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-1.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, 2021-09-17 at 08:54 +0000, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/10/routine-vacuuming.html > Description: > > Hi All, > I have a doubt about the vacuum_freeze_min_age explanation here; > https://www.postgresql.org/docs/10/routine-vacuuming.html > "vacuum_freeze_min_age controls how old an XID value has to be before rows > bearing that XID will be frozen. Increasing this setting may avoid > unnecessary work if the rows that would otherwise be frozen will soon be > modified again, but decreasing this setting increases the number of > transactions that can elapse before the table must be vacuumed again." > > Shouldn't the "Increasing" and "decreasing" words there interchange the > places? > Isn't decreasing value for vacuum_freeze_min_age causes vacuum to freeze > tuples soon due to reduced age? So it reduces number of transactions that > can elapse before the table must be vacuumed. > Please let me know if my understanding is incorrect. The documentation is correct. If you increase the parameter, rows will be frozen later, so if the rows get deleted before they would get frozen, you save the work of freezing them. If you decrease the parameter, rows get frozen earlier, so the time until anti-wraparound vacuum is necessary will increase. Yours, Laurenz Albe