On Tue, Jun 6, 2023 at 6:52 AM Andrew Dunstan <andrew@dunslane.net> wrote:
> If we were starting out today we would probably choose a threaded implementation. But moving to threaded now seems to
melike a multi-year-multi-person project with the prospect of years to come chasing bugs and the prospect of fairly
modestadvantages. 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.