On Tue, Jun 6, 2023 at 6:52 AM Andrew Dunstan <and...@dunslane.net> wrote: > If we were starting out today we would probably choose a threaded > implementation. But moving to threaded now seems to me like a > multi-year-multi-person project with the prospect of years to come chasing > bugs and the prospect of fairly modest advantages. The risk to reward doesn't > look great. > > That's my initial reaction. I could be convinced otherwise.
Here is one thing I often think about when contemplating threads. Take a look at dsa.c. It calls itself a shared memory allocator, but really it has two jobs, the second being to provide software emulation of virtual memory. That’s behind dshash.c and now the stats system, and various parts of the parallel executor code. It’s slow and complicated, and far from the state of the art. I wrote that code (building on allocator code from Robert) with the expectation that it was a transitional solution to unblock a bunch of projects. I always expected that we'd eventually be deleting it. When I explain that subsystem to people who are not steeped in the lore of PostgreSQL, it sounds completely absurd. I mean, ... it is, right? My point is that we’re doing pretty unreasonable and inefficient contortions to develop new features -- we're not just happily chugging along without threads at no cost.
