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 1ofaFI-00052E-Br for pgsql-hackers@arkaria.postgresql.org; Tue, 04 Oct 2022 05:13:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ofaFG-0000qy-VV for pgsql-hackers@arkaria.postgresql.org; Tue, 04 Oct 2022 05:13:30 +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 1ofaFG-0000mp-KP for pgsql-hackers@lists.postgresql.org; Tue, 04 Oct 2022 05:13:30 +0000 Received: from mail-pj1-x1033.google.com ([2607:f8b0:4864:20::1033]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ofaFE-0002Dk-8W for pgsql-hackers@lists.postgresql.org; Tue, 04 Oct 2022 05:13:29 +0000 Received: by mail-pj1-x1033.google.com with SMTP id v10-20020a17090a634a00b00205e48cf845so17562909pjs.4 for ; Mon, 03 Oct 2022 22:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20210112.gappssmtp.com; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date; bh=jlpuC5J39KnEowWD3hh1XKt/HUWFzgVFS6IxSu2g56M=; b=gHhmtPZlAtydJBgNZTUsGhHXMQnHPp8Q9BgOWHGyL02AYPMGPEgYwagr64fMRopJWF bRN0n6fuKKpdIPDn7ki7UeYYJf8TN289gpPbtCk3MIMd/y9f4669BvBu1P6X7TKP659M 1/O5Hw9G5QMrUP1/8NXnTSDkRiSJojtWdejfBRO6fvcWSbrl9QULJzQryw6tXUb+BhrU zhgszdKtuNTV1ojKytA0tO4teav9cF2YigQR4X1iHEEyOl0oiMOCg+vcWn/oPGQpQUL8 7Nhvw0yszHjXmGzykLPl8X0L1ZcPhwEUlMovDGBQvRYtG1YhEYy/Jn7TPVLfNMbdbzrK 4u7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date; bh=jlpuC5J39KnEowWD3hh1XKt/HUWFzgVFS6IxSu2g56M=; b=MSuFoHsabNObfh1IlIldskiXYrnHafQRB7TVo3t87fug0hWz2hzNZ6m7Mf3E7q5IN+ 7nbxyueQs8BCyKBvPWWxcYY9UPRRSFPo4lofYYpWaV+R1MkW3blEueQKdsLFLlGu6vpV /t/QLwk5cXS68w8bX6yl7dPCqZdfpA98/PFLqIa+axISzvqYRYw930rdD271a++TtJ/X EX1ASjwZA0h/+/Ovv4/nyqWDYREu4SmgywKTksjfSuFeOx9+jJG1NWajVaTh8YGeHVhI zxNI5w4iuRdszT2WK/Sthj1tiNaR/c3j29kCa5gxmuO5dbo+4PWAELKNnoZGlpE+90iC Lytg== X-Gm-Message-State: ACrzQf1VLM9Kwg3gM5j6wk9bxETqRSID+eWEDarH27wBbklq4K99se+z tUaLqW4yNdLQ6ApRA1ynEqJTwkiqqcA+Lg== X-Google-Smtp-Source: AMsMyM74LKfShl47Xq5QZzpugKlRLR2aNeQBAqsT87ZiLvf78VTV/E1mNjE8IU46C4NlTZPiUV3LxA== X-Received: by 2002:a17:902:b08b:b0:178:48b6:f5a8 with SMTP id p11-20020a170902b08b00b0017848b6f5a8mr25170225plr.3.1664860405993; Mon, 03 Oct 2022 22:13:25 -0700 (PDT) Received: from jeff-laptop.lan (c-73-231-146-4.hsd1.ca.comcast.net. [73.231.146.4]) by smtp.gmail.com with ESMTPSA id n12-20020a170902f60c00b001769e6d4fafsm5604766plg.57.2022.10.03.22.13.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Oct 2022 22:13:25 -0700 (PDT) Message-ID: <9bc85fb435df6f5fc2ececc00c0a086d41b755b4.camel@j-davis.com> Subject: Re: New strategies for freezing, advancing relfrozenxid early From: Jeff Davis To: Peter Geoghegan Cc: PostgreSQL Hackers Date: Mon, 03 Oct 2022 22:13:24 -0700 In-Reply-To: References: <1892cc797f86924e31f00fd3c703ca464936c65e.camel@j-davis.com> <424877f4840495235b9be5cacc65a2b84d000566.camel@j-davis.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.1-0ubuntu1 MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, 2022-10-03 at 20:11 -0700, Peter Geoghegan wrote: > True. Though I think that a strong bias in the direction of advancing > relfrozenxid by some amount (not necessarily by very many XIDs) still > makes sense, especially when we're already freezing aggressively. Take the case where you load a lot of data in one transaction. After the loading transaction finishes, those new pages will soon be marked all-visible. In the future, vacuum runs will have to decide what to do. If a vacuum decides to do an aggressive scan to freeze all of those pages, it may be at some unfortunate time and disrupt the workload. But if it skips them all, then it's just deferring the work until it runs up against autovacuum_freeze_max_age, which might also be at an unfortunate time. So how does your patch series handle this case? I assume there's some mechanism to freeze a moderate number of pages without worrying about advancing relfrozenxid? Regards, Jeff Davis