Hi there, would you like to share the progress of converting PGlite into a native system library? I can see there is a repo for that, but it hasn't been updated for 5 months
We are actively looking into it. But as you can see from the comments here, there are quite a lot of other features that users want and we have limited bandwidth. We will do it!
> a task can yield, which, conceptually, creates a new piece of work that gets shoved onto the work queues (which is "resume that task"). You might not think of it as "this task is suspended and will be resumed later" as much as *"this piece of work is done and has spawned a new piece of work."*
Never thought of it that way, but it’s indeed true — a new task does get enqueued in that case. Thanks for the insight!
Regarding write-heavy workloads, especially for Postgres, I think we really need to distinguish between INSERTs and UPDATEs, because every update to a tuple in Postgres duplicates the whole tuple due to its MVCC implementation (if you use the default heap storage engine)
One thing that catches people by surprise is that read heavy workloads can generate heavy writes.
Queries that need to operate on more data than will fit in the allocated working memory will write to a temporary table on disk, then in some cases perform an operation on that temporary table like sorting the whole thing and finally, after it's done delete it which is even more disk write stress.
It's not really about whether it's ready heavy or write heavy, it's about whether it's usage creates Disk I/O stress.
You can write millions of increment integers and while technically that's "write heavy", there's no stress involved because you're just changing the value in a defined space that's already been allocated. Update space that is more dynamic, like growing a TEXT or JSON field frequently...it's a different story.
> Then asking you to run code before a meeting? No, that doesn't "save time", that is driving you to take actions when you don't yet know who is asking.
Interesting project. Has anyone tried adopting something like this in their database cluster? I would like to know how it performs in practice. Is it useful?
I tried using a Dasung e-ink monitor, then I asked for a refund because I cannot review PRs on it. Even though it is a color e-ink monitor, I could barely tell if a line of diff was an addition (green) or a removal (red)
Kaleido color eInk is a dead-end. The displays are too dark to use in anything but direct sunlight. I regret purchasing such a display.
However, black and white eInk is great to use in any well-lit environment and doesn't need direct sunlight. However, the lack of color can be fatal for many workflows.
> My goal with the early sub-projects isn't to build a *finished* sub-component, it is to build a good enough sub-component so I can move on to the next thing on the path to a demo.
This is so enlightening. And I realized that to do this, one has to "skip" something. Other folks mention they ignore code modularity when doing this, I don't think I will do that, keeping code clean and reading/working in such a codebase actually make me satisfied and motivated. For me, I am going to "skip" algorithms, data strucuture and performance.
So the point here is probably, we should skip things, but if a thing motivates you, it should not skipped?
Maybe it's just media bias, but I have seen interest and work for GNOME really drop off the last couple of years. You could see something cool being worked on every couple weeks (at least reported on).
I remember this goal to change the window management to be more like a tiling WM (similar to Niri) that seems to have faded away. I recently moved from GNOME to KDE, one reason being KDE adopting Wayland protocols quicker and constant performance issues with GNOME.
