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 1taPKO-001ZfY-BW for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Jan 2025 01:14: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 1taPKN-0098pr-EF for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Jan 2025 01:14:43 +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 1taPKN-0098ph-4e for pgsql-hackers@lists.postgresql.org; Wed, 22 Jan 2025 01:14:43 +0000 Received: from m16.mail.163.com ([220.197.31.2]) by magus.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1taPKH-000oSU-2D for pgsql-hackers@lists.postgresql.org; Wed, 22 Jan 2025 01:14:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:Subject:Date:Message-ID:MIME-Version: Content-Type; bh=wjkqBdbNq8B7BtULaGI7189iWeOVxESClubq59WlZKw=; b=a2EurTubPnlXuSlpEoZn31hKV7QZFk79JxLxf3+RQ2eqpefj/1lc2BdWZBSwY4 78JbDSgNO4dvITr6bldMe12Sbw26RHAP2L2CbGxXefEd5g5wcqdY4t7Auntc4I3E oMnntupsUv2pAC++5L/6z2eDhMTyNv2QYkwoW17DcBO3U= Received: from lovely-coding (unknown [219.151.179.207]) by gzsmtp3 (Coremail) with SMTP id PigvCgDnmZtuRpBnREf1Jw--.10713S3; Wed, 22 Jan 2025 09:14:22 +0800 (CST) From: Andy Fan To: Andres Freund Cc: Nathan Bossart , Justin Pryzby , Maxim Orlov , Pavel Borisov , "Bossart, Nathan" , Maxim Orlov , pgsql-hackers@lists.postgresql.org Subject: Re: Pre-allocating WAL files In-Reply-To: (Andres Freund's message of "Tue, 21 Jan 2025 11:23:06 -0500") References: <20220301144044.GG25269@telsasoft.com> <20220301150704.GA1030078@nathanxps13> <20220317231212.GB1415284@nathanxps13> <20220408203003.GA1630183@nathanxps13> <87sepc4zcg.fsf@163.com> Date: Wed, 22 Jan 2025 01:14:22 +0000 Message-ID: <87o6zz4pld.fsf@163.com> MIME-Version: 1.0 Content-Type: text/plain X-CM-TRANSID: PigvCgDnmZtuRpBnREf1Jw--.10713S3 X-Coremail-Antispam: 1Uf129KBjvdXoW7JF13ZryxGF4rAF45GrWkCrg_yoW3WrXE9a s5XFn2qa4kCr4xXan3Ar47XFW5XrZ2kFy5Zw47Xr4fKry8AFZ5CFyjv3WIqry7Kw1Iyr90 kFs0kryagr13ujkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUvcSsGvfC2KfnxnUUI43ZEXa7xRRBMN5UUUUU== X-Originating-IP: [219.151.179.207] X-CM-SenderInfo: x2klx3xlid0iqsrtqiywtou0bp/1tbioBHcU2eQOKzOOAAAsr List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andres Freund writes: Hi, > FWIW, I've seen the fsyncs around recycling being a rather substantial > bottleneck. To the point of the main benefit of larger segments being the > reduction in number of fsyncs at the end of a checkpoint. I think we should > be able to make the fsyncs a lot more efficient by batching them, first rename > a bunch of files, then fsync them and the directory. The current pattern > bascially requires a separate filesystem jouranl flush for each WAL segment. For education purpose, how to fsync files in batch? 'man fsync' tells me user can only fsync one file each time. int fsync(int fd); The fsync manual seems not saying fsync on a directory would fsync all the files under that directory. -- Best Regards Andy Fan