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
> 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)
> 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)
> 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?