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 1s17fJ-009awL-B7 for pgsql-general@arkaria.postgresql.org; Sun, 28 Apr 2024 16:46:13 +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 1s17fG-00DTiA-1V for pgsql-general@arkaria.postgresql.org; Sun, 28 Apr 2024 16:46:10 +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 1s0UnJ-00H95D-Ca for pgsql-general@lists.postgresql.org; Fri, 26 Apr 2024 23:15:54 +0000 Received: from mail-pg1-x52c.google.com ([2607:f8b0:4864:20::52c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s0UnE-000FNW-Jt for pgsql-general@lists.postgresql.org; Fri, 26 Apr 2024 23:15:53 +0000 Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-5d8b887bb0cso2265719a12.2 for ; Fri, 26 Apr 2024 16:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714173346; x=1714778146; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2WaTsRzGm523pV1ErQNGKref/YPwSd3V+h+MHJEgTqw=; b=VOXe2GESVXNhD+rZiSE6OIckhJXEsTFmJpUL0CHYBYjnOUblJrtueJFvLirwgPl8W1 lGRQTEjEw4rB6NJ8p4Z+lJwHFwiPz8qtieybCizwLTlOLU7R4tuMi+rq3/uibvMh8eMc GqD+hjq2dhB0WzAr6hHLdmWVZFBRwbARlpTrmXIYXhjkNzp4BL30BDOs9GnfuGrGfKE2 rswoW4bEeRcwsRLc7+cEjj+U1PQ4e49g8orcuhuBA+Tonb/25TjvnL3dJESfqnMv1brm opJTYTA9fcROGZE/pKOYPCoWdDiQelozhF1O4tIF5rw6aqvBUz76ZFI93cwQkvi4O1DR p6yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714173346; x=1714778146; h=cc: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=2WaTsRzGm523pV1ErQNGKref/YPwSd3V+h+MHJEgTqw=; b=ZEEM0zCBiP9ngT9vf2e+os3RJOdVeEgA8x/V5ry356L8UbVcp00uLorojUubKEQLb8 zglwDhHN6C000upbexHv2q5RKpa5PNoS3MJaIdF8KLQ7URP/cKn8le7WHOhLHP+OvPFv y3pENilf2zb96tMTVPi+vIV2gl92M8wLsTvwB6Cyu/OJPB0zUNSHMKP64VrKEbtRUi09 4oitkges69aac2QvfVeVIKe1NgeGIVmy1DWUTOYZxDJfFhByMEfOhM4LD1oMrxHWLLm0 Pri0aFpY78bZFGa3rqkbCqON23j1pZww2LiHsy4DY6IMMC6EH72g/DcRQfsM1/xCQlg8 TPUA== X-Gm-Message-State: AOJu0Yw+ugpt1nyivtlTr2+JSgw+tjUmX+C3igFnB9uDKggT/23ioAgY tlYho677OTdiYIhlOz7s1x2QaYndNFgDm8Gu44Lpf04vBqB8p/7gFIo9aL9jl2lQkpRnXmmBlLM yP8Z5Ab6G+KtwZN6TXq6SGjIALPQ= X-Google-Smtp-Source: AGHT+IGVaXV098hpzUroy6v4huiCzrA6/2aqEgpfEcYcE+vFyx5TpY+Y15pwb+vE/Rj/A0DO086FwgYVY86TNJxo/vw= X-Received: by 2002:a17:90a:654c:b0:2ac:dbec:2d6f with SMTP id f12-20020a17090a654c00b002acdbec2d6fmr4521901pjs.39.1714173345953; Fri, 26 Apr 2024 16:15:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Riku Iki Date: Fri, 26 Apr 2024 16:15:35 -0700 Message-ID: Subject: Re: Preallocation changes in Postgresql 16 To: Thomas Munro Cc: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000005e95650617081579" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000005e95650617081579 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you, I have such a system. I think my task would be to compile PG from sources(need to learn this), and see how it works with and without that code block. On Thu, Apr 25, 2024 at 2:25=E2=80=AFPM Thomas Munro wrote: > On Fri, Apr 26, 2024 at 4:37=E2=80=AFAM Riku Iki w= rote: > > I am wondering if there were preallocation related changes in PG16, and > if it is possible to disable preallocation in PostgreSQL 16? > > I have no opinion on the btrfs details, but I was wondering if someone > might show up with a system that doesn't like that change. Here is a > magic 8, tuned on "some filesystems": > > /* > * If available and useful, use posix_fallocate() (via > * FileFallocate()) to extend the relation. That's often more > * efficient than using write(), as it commonly won't cause the > kernel > * to allocate page cache space for the extended pages. > * > * However, we don't use FileFallocate() for small extensions, as > it > * defeats delayed allocation on some filesystems. Not clear wher= e > * that decision should be made though? For now just use a cutoff > of > * 8, anything between 4 and 8 worked OK in some local testing. > */ > if (numblocks > 8) > > I wonder if it wants to be a GUC. > --0000000000005e95650617081579 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you, I have such a system. I think my task would be = to compile PG from sources(need to learn this), and see how it works with a= nd without that code block.

On Thu, Apr 25, 2024 at 2:25=E2=80=AFPM Thomas M= unro <thomas.munro@gmail.com> wrote:
On= Fri, Apr 26, 2024 at 4:37=E2=80=AFAM Riku Iki <riku.iki.x@gmail.com> wrote:
> I am wondering if there were preallocation related changes in PG16, an= d if it is possible to disable preallocation in PostgreSQL 16?

I have no opinion on the btrfs details, but I was wondering if someone
might show up with a system that doesn't like that change.=C2=A0 Here i= s a
magic 8, tuned on "some filesystems":

=C2=A0 =C2=A0 =C2=A0 =C2=A0 /*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* If available and useful, use posix_fall= ocate() (via
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* FileFallocate()) to extend the relation= . That's often more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* efficient than using write(), as it com= monly won't cause the kernel
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* to allocate page cache space for the ex= tended pages.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* However, we don't use FileFallocate= () for small extensions, as it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* defeats delayed allocation on some file= systems. Not clear where
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* that decision should be made though? Fo= r now just use a cutoff of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* 8, anything between 4 and 8 worked OK i= n some local testing.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (numblocks > 8)

I wonder if it wants to be a GUC.
--0000000000005e95650617081579--