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 1pjGeC-0006sI-Sr for pgsql-admin@arkaria.postgresql.org; Mon, 03 Apr 2023 09:38:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pjGeA-0005Xf-Vv for pgsql-admin@arkaria.postgresql.org; Mon, 03 Apr 2023 09:38:42 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pjGeA-0005XW-ID for pgsql-admin@lists.postgresql.org; Mon, 03 Apr 2023 09:38:42 +0000 Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pjGe2-0001mO-4U for pgsql-admin@lists.postgresql.org; Mon, 03 Apr 2023 09:38:41 +0000 Received: by mail-ed1-x52e.google.com with SMTP id b20so114765013edd.1 for ; Mon, 03 Apr 2023 02:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20210112.gappssmtp.com; s=20210112; t=1680514712; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:from:to:cc:subject:date :message-id:reply-to; bh=ZgmLRrtVpuC75gsGG1TtD/uSG9N9M4ZH2ELtHhS7+VA=; b=Auj/tMmGMyCcbr3qFuT+TbJP8KeCtRJIh+WEmYHfte3RL71t4IgGhhBhGoDU+MFurG FZAzXz2pb0P/AM16uKTZXLKRBdR+KMOxJbc+dFcoCAsZRnsKRgGyJZUdGm/sTqBdwKwN hHUlbdg08Zz3BlOakDKAZnuud2JC9ndF1JRDW0ojD9aLrUFQnCzfkH0UmuWCV8VaLQfw SQ1erSkJjhvR22Sc3aezswvujfxLBDE3J3USyIKxMhJPcjZUn2GvpHmFfE7aMVWrCB1F Znd7AocsYSkkMi5q0CyYGn2MpfALRuqcSG6YVpMIMz/hclTqNYuMRb/cUaD9wYFm47Sk FI4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680514712; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=ZgmLRrtVpuC75gsGG1TtD/uSG9N9M4ZH2ELtHhS7+VA=; b=4mj6kduHoStkUm4NgMMi0k1SUUOAiuNh0lQjv+5pMXFQnZbsXMODr/qYwgaiCajIE7 DLzxPkSzrnyTZybDncsV/O5jxYqgoIjUvVKMSmF1NXOIoB9vDj2rgupkEP4/6ljiXPD3 oWKDIEEmizYOVhHYmmjr5tkzcRyyf7tIoQurFCshZOluQIeqGahHSxgVH0tad53ugs7j w081ATJWljeku9G/B5uDaF5YQ9zzV8e1Xxgyj8VpMRNUynEqj7rBF7sG1yG9KYfCTM4Z qFsPDS2RihPST4hpgQuN6NcVKAafeeo//QzB+yPqQtGFpO9Jlq1h4HV4wRkMz85i9A50 21Yw== X-Gm-Message-State: AAQBX9f1z7bgg4f6o0McUzFvR3bctrF1dfkdrJJYbu31Cf4J2vdMaYeb 33HMLR/XTEFfWnqyF4KdCEwEqg== X-Google-Smtp-Source: AKy350aTMB1Y04d2F9v8wc+EsqVgz/+agLu8+gXMZ0R2xEfjMjrnnIX3Ur2JH9Zi4dMs98m5lLbhGQ== X-Received: by 2002:a17:906:1514:b0:92b:ae6c:23e7 with SMTP id b20-20020a170906151400b0092bae6c23e7mr34641927ejd.56.1680514711822; Mon, 03 Apr 2023 02:38:31 -0700 (PDT) Received: from localhost.localdomain ([2001:871:5e:6aca:140f:2a2:608:8640]) by smtp.gmail.com with ESMTPSA id k29-20020a50ce5d000000b005021d210899sm4306993edj.23.2023.04.03.02.38.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Apr 2023 02:38:31 -0700 (PDT) Message-ID: <942e247261151cddf5d57cf7797d6bf3c9b067a7.camel@cybertec.at> Subject: Re: A Question about FPW and WAL From: Laurenz Albe To: Dawn Yu , pgsql-admin@lists.postgresql.org Date: Mon, 03 Apr 2023 11:38:30 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, 2023-04-03 at 14:51 +0800, Dawn Yu wrote: > Recently=EF=BC=8Cwe come=C2=A0up with a same=C2=A0problem=EF=BC=8Cwhen th= e database make the checkpoint, > the=C2=A0size of wal directory=C2=A0increase very fast and=C2=A0 take one= hundred percent disk > usage,we found the problem of pg wal write amplification is very serious. > By analyzing the wal log, in some scenarios, most of the space is wasted = when > maintaining the full page of the index. Has the community considered modi= fying > this part of the relevant code to make the full page better,The setting o= f FPW > function is divided into two parts, the full-page write of the data recor= d and > the full-page write of the index block, and the switch functions can be s= et > separately. > By default, index full-page write is disabled. If the index is broken, yo= u can > rebuild the index to solve it. Although the security of index data cannot= be > guaranteed, this setting can greatly reduce the problem of storage space = explosion > caused by wal write amplification. I would feel funny about a parameter like that. There are a couple of things you can do today: - increase "max_wal_size" and "checkpoint_timeout" to get checkpoints less = often - activate "wal_compression", so that the FPW are compressed. Best is to u= se v15, where you can use "lz4" or "zstd" compression, which are much faster. Yours, Laurenz Albe