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 1u92Sy-00ElkT-Uh for pgsql-general@arkaria.postgresql.org; Sun, 27 Apr 2025 13:54:45 +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 1u92Sv-009DLo-63 for pgsql-general@arkaria.postgresql.org; Sun, 27 Apr 2025 13:54:42 +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 1u92Su-009DLf-O9 for pgsql-general@lists.postgresql.org; Sun, 27 Apr 2025 13:54:41 +0000 Received: from mail-oi1-x22f.google.com ([2607:f8b0:4864:20::22f]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1u92Ss-002Kwj-0l for pgsql-general@postgresql.org; Sun, 27 Apr 2025 13:54:41 +0000 Received: by mail-oi1-x22f.google.com with SMTP id 5614622812f47-3f6aa4b3a7fso1195920b6e.3 for ; Sun, 27 Apr 2025 06:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745762077; x=1746366877; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=4woyxh+sXlMtU2L50IlhAfB2gqKSR0xP/uoWGKnWwGI=; b=W07opOsuYimgUVVXxMdwcWU3YRVXwOixooBKCRlQHpBl2SqaIyRuTrQZuvbzd/EQFW /8FrP/RlSA2Dpg+6fogfhcVtGDWJ6T0Q3C/WlFyuSyE3W9UbZ9tGr/kdA69NXnl9JJhZ AJZJ1+c8DP5gdGFo30fbpT+ECbspGmaqB9AZjfCMrvm6CcB8eFBDjVQHloeqgiD+kYS3 ESPHD100fv4tkMDORERcpuTMv/C10g/gQIvV6eOODKhPycW6kf0Wl//Exr/maRXDRK9t J1ByoQ9TsfXyPnWGsLiUnh+6PsmAtzcmm0bg6j122WurnxVRmjTZXnb6EyyfXD5fTwgO rXwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745762077; x=1746366877; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4woyxh+sXlMtU2L50IlhAfB2gqKSR0xP/uoWGKnWwGI=; b=q4NygKbK37DDU5MHnGFxmIDWCsYBZb01tdjC3YS5WDG9GeN6Dbf73Zr9jFcVVHoGXw nnVHyXyMyuupQwbwyReV6KF/gQdQ+/mTBF+TiepKnSAJlZYjpN3o0AJ7nyxc+RiB4fnP 8hQ0cqpt5gTPSeGJaJpaRue64Q+2SRpSUkpHMZhBz5hL3ZJqz633LylKHbk6tlfHhRvd nQCWoryopsSMrqQl+tFCREOisEWq8+ZP8xCZ7Px+t9FAXXpqbdgW8Konna0O3CyWGhAk 6r9bWYGkXn0VtPmNNf4aw152KYEuEShXeHl89lYqhdV76ZfV3a1Hg7dzaLDARMMcQvHj 0y5A== X-Gm-Message-State: AOJu0Yz/fpbFhMPGFDVgACYlWCbfigtuoZBESpI8m3lMJg1icQJYcNSO DtFnEYoYmRVFHoH+HU2GNCUmbu+mlM25UyLpFIZEpcxSAZn7TrcdSTEg0OIsLiwDGdcCny2mgpI PrSJbz7oBpWqAmn6DmnOpKuuEYvfrVA== X-Gm-Gg: ASbGncsLceWX4QoDpFQnmSFLxl/wYBfh6/6+fvCXL0C7ligSsdt3hPwD8sBxj+ReH45 G4K9b7AVmHG60o1lIb5ALDgAtdg9NYXzcM5LetdDe6qnrmVpt7jE0J48ICB8aHE7aPZYEwwFv+6 m4sUfAjvOQbDmKEbqfgGJwkIc= X-Google-Smtp-Source: AGHT+IEchbPaLrL0ji15fkLVpe9TIuQLE3uneSv6jKEChHLHfkqcTyBJ4BYdxgmJFl22raIOV6OQG0ZWwi1Hh0rDw1k= X-Received: by 2002:a05:6808:3191:b0:401:e6e7:b561 with SMTP id 5614622812f47-401f28ad76fmr5398565b6e.21.1745762076687; Sun, 27 Apr 2025 06:54:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Sun, 27 Apr 2025 09:54:24 -0400 X-Gm-Features: ATxdqUGlq7ZgiqeAosuTSyhUMmGBuFUtv6WGh2FJggrZ83zuNOh_bKPyJn5svfU Message-ID: Subject: Re: Changing default fillfactor for the whole database To: pgsql-general Content-Type: multipart/alternative; boundary="0000000000007184810633c2e8df" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000007184810633c2e8df Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Apr 26, 2025 at 10:31=E2=80=AFPM Marcelo Fernandes wrote: > Hi there, > > I have a scenario where virtually all user tables in the database will > need to > have a lower fill factor. > > It would have been handy to have a way to set this default, but as of now= , > I > don't think the default can be changed. > > I have looked at `share/postgresql.conf.sample` file, and couldn't see > anything indicating this value could be changed. > > Though I'm aware there's an ALTER TABLE command that can be used for that= , > I > think it would be good to avoid some future errors (forgetting to set it) > if I > could change the default value. > > Does this make sense? Have I missed something about being able to change > this > on a database level? > Following Christophe's post: it's possible to query the catalog to find tables which do not have a fill factor. Combine that with format() and \gexec to get a script you can run weekly, to catch new tables which you forgot to set when creating. I agree with him, though, that this a foot-gun: most table's aren't that UPDATE heavy. Run pgstattuple and pgstatindex every week (I do it on Sundays around 05:00 local time, and store the results in a table; makes it easy to find bloated tables), and only change the fill factor on consistently bloated tables. --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --0000000000007184810633c2e8df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Apr 26, 2025 at 10:31=E2=80=AFPM = Marcelo Fernandes <marcefern7@gm= ail.com> wrote:
Hi there,

I have a scenario where virtually all user tables in the database will need= to
have a lower fill factor.

It would have been handy to have a way to set this default, but as of now, = I
don't think the default can be changed.

I have looked at `share/postgresql.conf.sample` file, and couldn't see<= br> anything indicating this value could be changed.

Though I'm aware there's an ALTER TABLE command that can be used fo= r that, I
think it would be good to avoid some future errors (forgetting to set it) i= f I
could change the default value.

Does this make sense? Have I missed something about being able to change th= is
on a database level?

Following Christop= he's post: it's possible to query the catalog to find tables which = do not have a fill factor.=C2=A0 Combine that with format() and \gexec to g= et a script you=C2=A0can run weekly, to catch new tables which you forgot t= o set when creating.

I agree with him, though, tha= t this a foot-gun: most table's aren't that UPDATE heavy.=C2=A0 Run= pgstattuple and pgstatindex every week (I do it on Sundays around 05:00 lo= cal time, and store the results in a table; makes it easy to find bloated t= ables), and only change the fill factor on consistently bloated tables.

--
Death to <R= edacted>, and butter sauce.
Don't boil me, I'm still alive.<= br>
<Redacted> lobster!
--0000000000007184810633c2e8df--