From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Vectored I/O in bulk_write.c |
Date: | 2024-03-13 21:12:32 |
Message-ID: | CA+hUKGLzgXSC026GjSuNXFthcAzskeM5msxQkDKquuOy6Dn1FQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alright, here is a first attempt at merging all three interfaces as
you suggested. I like it! I especially like the way it removes lots
of duplication.
I don't understand your argument about the location of the
write-vs-extent assertions. It seems to me that these are assertions
about what the *public* smgrnblocks() function returns. In other
words, we assert that the caller is aware of the current relation size
(and has some kind of interlocking scheme for that to be possible),
according to the smgr implementation's public interface. That's not
an assertion about internal details of the smgr implementation, it's
part of the "contract" for the API.
Attachment | Content-Type | Size |
---|---|---|
v4-0001-Merge-smgrzeroextend-and-smgrextend-with-smgrwrit.patch | text/x-patch | 22.8 KB |
v4-0002-Use-vectored-I-O-for-bulk-writes.patch | text/x-patch | 4.7 KB |
v4-0003-Improve-bulk_write.c-memory-management.patch | text/x-patch | 5.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2024-03-13 21:49:49 | Re: Vectored I/O in bulk_write.c |
Previous Message | David Steele | 2024-03-13 20:12:52 | Re: Add basic tests for the low-level backup method. |