On Sat, Jan 15, 2022 at 1:36 PM Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote: > > On Thu, Jan 6, 2022 at 3:39 AM Bossart, Nathan <bossa...@amazon.com> wrote: > > > > On 12/30/21, 3:52 AM, "Maxim Orlov" <orlo...@gmail.com> wrote: > > > I did check the patch too and found it to be ok. Check and check-world > > > are passed. > > > Overall idea seems to be good in my opinion, but I'm not sure where is > > > the optimal place to put the pre-allocation. > > > > > > On Thu, Dec 30, 2021 at 2:46 PM Pavel Borisov <pashkin.e...@gmail.com> > > > wrote: > > >> I've checked the patch v7. It applies cleanly, code is good, check-world > > >> tests passed without problems. > > >> I think it's ok to use checkpointer for this and the overall patch can > > >> be committed. But the seen performance gain makes me think again before > > >> adding this feature. I did tests myself a couple of months ago and got > > >> similar results. > > >> Really don't know whether is it worth the effort. > > > > Thank you both for your review. > > It may have been discussed earlier, let me ask this here - IIUC the > whole point of pre-allocating WAL files is that creating new WAL files > of wal_segment_size requires us to write zero-filled empty pages to > the disk which is costly. With the advent of > fallocate/posix_fallocate, isn't file allocation going to be much > faster on platforms where fallocate is supported? IIRC, the > "Asynchronous and "direct" IO support for PostgreSQL." has a way to > use fallocate. If at all, we move ahead and use fallocate, then the > whole point of pre-allocating WAL files becomes unnecessary? > > Having said above, the idea of pre-allocating WAL files is still > relevant, given the portability of fallocate/posix_fallocate.
Adding one more point: do we have any numbers like how much total time WAL files allocation usually takes, maybe under a high-write load server? Regards, Bharath Rupireddy.
