Re: Vectored I/O in bulk_write.c

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Vectored I/O in bulk_write.c
Date: 2024-03-19 20:10:02
Message-ID: CA+hUKGL+aVoMtLKFZufEAkr1KpKhyHHL6ELAUm9kZcCq8q7UTA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Mar 17, 2024 at 8:10 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I don't think zeroextend on the one hand and and on the other hand a normal
> write or extend are really the same operation. In the former case the content
> is hard-coded in the latter it's caller provided. Sure, we can deal with that
> by special-casing NULL content - but at that point, what's the benefit of
> combinding the two operations? I'm not dead-set against this, just not really
> convinced that it's a good idea to combine the operations.

I liked some things about that, but I'm happy to drop that part.
Here's a version that leaves smgrzeroextend() alone, and I also gave
up on moving errors and assertions up into the smgr layer for now to
minimise the change. So to summarise, this gives us smgrwritev(...,
flags), where flags can include _SKIP_FSYNC and _EXTEND. This way we
don't have to invent smgrextendv(). The old single block smgrextend()
still exists as a static inline wrapper.

Attachment Content-Type Size
v6-0001-Use-smgrwritev-for-both-overwriting-and-extending.patch application/octet-stream 20.0 KB
v6-0002-Use-vectored-I-O-for-bulk-writes.patch application/octet-stream 5.0 KB
v6-0003-Improve-bulk_write.c-memory-management.patch application/octet-stream 5.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2024-03-19 20:22:35 Re: Avoiding inadvertent debugging mode for pgbench
Previous Message Nathan Bossart 2024-03-19 19:59:18 Re: Popcount optimization using AVX512