smgrextendv and vectorizing the bulk_write implementation

From: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: smgrextendv and vectorizing the bulk_write implementation
Date: 2024-11-22 17:49:31
Message-ID: CAEze2WgMt_WaD_cGCXuWdAA5-BTAm-xtWES4D_tQTaYyR9WF_g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

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?

Kind regards,

Matthias van de Meent
Neon (https://neon.tech)

[0] https://postgr.es/m/flat/CACAa4VJ%2BQY4pY7M0ECq29uGkrOygikYtao1UG9yCDFosxaps9g%40mail.gmail.com

Attachment Content-Type Size
v0-0001-Vectorize-smgrextend.patch application/octet-stream 10.1 KB
v0-0002-Modernize-bulk_write-s-internals-with-vectorized-.patch application/octet-stream 3.6 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kirill Reshke 2024-11-22 18:04:32 Re: Allow non-superuser to cancel superuser tasks.
Previous Message Andres Freund 2024-11-22 17:28:18 Re: ci: Macos failures due to MacPorts behaviour change