Re: Vectored I/O in bulk_write.c

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Vectored I/O in bulk_write.c
Дата
Msg-id CA+hUKGL+aVoMtLKFZufEAkr1KpKhyHHL6ELAUm9kZcCq8q7UTA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Vectored I/O in bulk_write.c  (Andres Freund <andres@anarazel.de>)
Ответы Re: Vectored I/O in bulk_write.c  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers
On Sun, Mar 17, 2024 at 8:10 AM Andres Freund <andres@anarazel.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.

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: Popcount optimization using AVX512
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: Avoiding inadvertent debugging mode for pgbench