On Wed, Jun 07, 2023 at 10:26:07AM +1200, Thomas Munro wrote:
> 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
tome like 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
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.
>