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 1tks6t-007Vxe-69 for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Feb 2025 22:00:03 +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 1tks6q-00EDGN-O8 for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Feb 2025 22:00:00 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tks6q-00EDGF-Ea for pgsql-hackers@lists.postgresql.org; Wed, 19 Feb 2025 22:00:00 +0000 Received: from mail-il1-x136.google.com ([2607:f8b0:4864:20::136]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tks6o-001qDC-1c for pgsql-hackers@postgresql.org; Wed, 19 Feb 2025 22:00:00 +0000 Received: by mail-il1-x136.google.com with SMTP id e9e14a558f8ab-3d2a8c2467eso884915ab.3 for ; Wed, 19 Feb 2025 13:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740002396; x=1740607196; darn=postgresql.org; 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=AoN+p6NkThJoHOa5pfhvl3IUvdWHw+gab71K+uZ7q00=; b=bGTeLmdV1ZZ7Wdx7wcPAenca7bmUyJFdrtTaJaJ7oaIWPifX/w/8y3edj/xFeAOGHw W/3tClf+vYrToR0L13OWGO4syVjEvDJK6WAOi6z2uwuERu5lcIIajvRaK05lO/uYrhqv o65Q9Yz7XKG7Vo7fkHLm9/9vE90gWpy5DTrWoyWjxUZUBgdzqM555OCWJCOTsoJc6dci x+CzwwC3B91ZPB+hR+5ivVJMCjB62vZFOKe1evHKaYqYp8MNe7qvAV2iiEYN/TICw8Jy qiQDBVBFicL1tFDkcF26z2bmkAj3j0JYXWKjbutf9hAQtF10AWGga9n2co+i904zKOQB peDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740002396; x=1740607196; 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=AoN+p6NkThJoHOa5pfhvl3IUvdWHw+gab71K+uZ7q00=; b=qy6E9NwkVIzIYXkdU/vllyYzvArlmICskMbl0t+8StzTJx/9QtrOEuFpHsHrBVv+TE 6RHam8/hvgMQGIdXOBp9G/4XGbWgkNMFMwCHdeuFbX2OnLw9uKKjgpgyOrpGELZurjRV bGznbbKPWHjgxXPOLJw1Q+GnPdg3COKZm2zQW7VHKWoojsl8v7+35a80jEBLBBB6SLRM J78Tr9CsN06e2uAN6/6cfHo1mriIFA9KX0EgLIHpfMta15ABVjHY4RJnj+kJx1oYzDPl nX32VY4GieUGV0qPdDA+gHv4QNmarAgTeL+Rwmh84Fh+aw56lcQ0/AOIHmbvoy9qDX9X cJnA== X-Gm-Message-State: AOJu0Yyye/nntH0vZO2NKWtQkCf4+Yndb1UYmC1MfsxSj1DpNl+ZYyl/ eyHCsxFLq/t93iv3gLPaD5qqC4qEqafBvAi/K7HBpivi1a2gePll X-Gm-Gg: ASbGncuOXwI28YTJZ6mCxoO1IjzkUXG0QgYqdf90mg3SLXBOKNGjhzV5SCBN+moeP0t eq8a7dvS9A2vJJPzou8B9SoNDsB0PDcsjDFXi4T2IIfpMaSDKFfVPeP9WO5D41R+AXtcG0D6FAM AcnxujHDnMrfLtaNgHhoeeXeDZqXpY2vKOCHr6ieFQ5MiTkOKtPWFq2kkOXGgO5Mv4LoKz+r3Io EQzeMERb5KuIGdR9nzY/E6D3MOS5lzbIZJy7VotXuVD9Ck9+PvbxxlmelMIjCTzHseJ4ativ44i RGjoO+7E26FdFdlG/y0k3YE74XC2747jBG7ZO+kxVs912v7Lek6EF+0xovOLlpd5JQCsrl4LAlB daTe2lQ== X-Google-Smtp-Source: AGHT+IHkNfl7i8KYcQleEXZ7aRQqI/cBaVuz0xU81kczHJeNrAFAJATjB0KmJf1jpALGvwYVU1mUzw== X-Received: by 2002:a05:6e02:3c05:b0:3d0:618c:1b29 with SMTP id e9e14a558f8ab-3d280763ee6mr160309215ab.5.1740002396204; Wed, 19 Feb 2025 13:59:56 -0800 (PST) Received: from nathan (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4eea0f29de7sm1452526173.27.2025.02.19.13.59.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Feb 2025 13:59:55 -0800 (PST) Date: Wed, 19 Feb 2025 15:59:54 -0600 From: Nathan Bossart To: Melanie Plageman Cc: Pg Hackers , Robert Haas , Andres Freund , Peter Geoghegan , David Rowley Subject: Re: Trigger more frequent autovacuums of heavy insert tables Message-ID: References: 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 Wed, Feb 19, 2025 at 04:36:05PM -0500, Melanie Plageman wrote: > This makes me think I should also not cap relallfrozen when using it > in relation_needs_vacanalyze(). There I cap it to relallvisible and > relallvisible is capped to relpages. One of the ideas behind letting > people modify these stats in pg_class is that they can change a single > field to see what the effect on their system is, right? Right. Capping these values to reflect reality seems like it could make that more difficult. >> Should we allow manipulating relallfrozen like we do relallvisible? My >> assumption is that would even be required for the ongoing statistics >> import/export work. > > Why would it be required for the statistics import/export work? It's probably not strictly required, but my naive expectation would be that we'd handle relallfrozen just like relallvisible, which appears to be dumped in the latest stats import/export patch. Is there any reason we shouldn't do the same for relallfrozen? -- nathan