Here's a rebase. I decided against committing this for v17 in the
end. There's not much wrong with it AFAIK, except perhaps an
unprincipled chopping up of writes with large io_combine_limit due to
simplistic flow control, and I liked the idea of having a decent user
of smgrwritev() in the tree,
Then I would make the trivial change to respect the new
io_combine_limit GUC that I'm gearing up to commit in another thread.
As attached.
From 7993cede8939cad9172867ccc690a44ea25d1ad6 Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Fri, 29 Mar 2024 00:22:53 +1300
Subject: [PATCH] fixup:
On Sun, Mar 17, 2024 at 8:10 AM Andres Freund 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
Hi,
On 2024-03-16 12:27:15 +1300, Thomas Munro wrote:
> I canvassed Andres off-list since smgrzeroextend() is his invention,
> and he wondered if it was a good idea to blur the distinction between
> the different zero-extension strategies like that. Good question. My
> take is that it's fine:
>
I canvassed Andres off-list since smgrzeroextend() is his invention,
and he wondered if it was a good idea to blur the distinction between
the different zero-extension strategies like that. Good question. My
take is that it's fine:
mdzeroextend() already uses fallocate() only for nblocks > 8,
On Thu, Mar 14, 2024 at 10:49 AM Heikki Linnakangas wrote:
> I tried to say that smgr implementation might have better ways to assert
> that than calling smgrnblocks(), so it would be better to leave it to
> the implementation. But what bothered me most was that smgrwrite() had a
> different
On 13/03/2024 23:12, Thomas Munro wrote:
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
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
On 13/03/2024 12:18, Thomas Munro wrote:
On Wed, Mar 13, 2024 at 9:57 PM Heikki Linnakangas wrote:
Here also is a first attempt at improving the memory allocation and
memory layout.
...
+typedef union BufferSlot
+{
+ PGIOAlignedBlock buffer;
+ dlist_node freelist_node;
+}
On Wed, Mar 13, 2024 at 9:57 PM Heikki Linnakangas wrote:
> Let's bite the bullet and merge the smgrwrite and smgrextend functions
> at the smgr level too. I propose the following signature:
>
> #define SWF_SKIP_FSYNC 0x01
> #define SWF_EXTEND 0x02
> #define SWF_ZERO
(Replying to all your messages in this thread together)
This made me wonder why smgrwritev() and smgrextendv() shouldn't be
backed by the same implementation, since they are essentially the same
operation.
+1 to the general idea of merging the write and extend functions.
The differences are
One more observation while I'm thinking about bulk_write.c... hmm, it
writes the data out and asks the checkpointer to fsync it, but doesn't
call smgrwriteback(). I assume that means that on Linux the physical
writeback sometimes won't happen until the checkpointer eventually
calls fsync()
Here also is a first attempt at improving the memory allocation and
memory layout.
I wonder if bulk logging should trigger larger WAL writes in the "Have
to write it ourselves" case in AdvanceXLInsertBuffer(), since writing
8kB of WAL at a time seems like an unnecessarily degraded level of
Slightly better version, adjusting a few obsoleted comments, adjusting
error message to distinguish write/extend, fixing a thinko in
smgr_cached_nblocks maintenance.
From c786f979b0c38364775e32b9403b79303507d37b Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Sat, 9 Mar 2024 16:04:21 +1300
Hi,
I was trying to learn enough about the new bulk_write.c to figure out
what might be going wrong over at [1], and finished up doing this
exercise, which is experiment quality but passes basic tests. It's a
bit like v1-0013 and v1-0014's experimental vectored checkpointing
from [2] (which
15 matches
Mail list logo
