On 22/11/2024 19:49, Matthias van de Meent wrote:
Hi,
While working on the fix for [0] I noticed that bulk_write doens't use
any of the new vectorized IO features, which seemed like a waste.
After looking into it a bit deeper, I noticed the opportunity for
write vectorization was not very high, as one would expect most
bulk_write IOs to be smgrextend(), which only does page-sized writes.
That's something that can be solved, though, and so I started this
patch.
+1
I've attached two patches to address these two items:
Patch 1/2 reworks smgrextend to smgrextendv, which does mostly the
same stuff as the current smgrextend, but operates on multiple pages.
Patch 2/2 updates bulk_write to make use of smgrwritev,
smgrzeroextend, and the new smgrextendv API, thus reducing the syscall
burden in processes that use bulk extend APIs.
Seems straightforward.
Thomas wrote patches earlier to do similar thing, see
https://www.postgresql.org/message-id/CA%2BhUKGLx5bLwezZKAYB2O_qHj%3Dov10RpgRVY7e8TSJVE74oVjg%40mail.gmail.com.
I haven't looked closely at the patches to see what the differences are.
Open question:
In my version of smgrextendv, I reject any failure to extend by the
requested size. This is different from smgrwrite, which tries to write
again when FileWriteV returns a short write. Should smgrextendv do
retries, too?
Hmm, a short write seems just as possible in smgrextendv() too, it
should retry.
In principle you could get a short write even with a BLCKSZ write. We've
always just assumed that it won't happen, or if it does it means you ran
out of disk space. I don't know why we ever assumed that, even though it
has worked in practice. But I think we should stop assuming that going
forward, and always retry short writes.
--
Heikki Linnakangas
Neon (https://neon.tech)
