On Wed, Jun 07, 2023 at 10:26:07AM +1200, Thomas Munro wrote: > 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
Isn't all the memory operations would require nearly the same shared memory allocators if someone switches to a threaded imple- mentation? > 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. >
