Re: Let's make PostgreSQL multi-threaded - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Let's make PostgreSQL multi-threaded
Date
Msg-id ZIebBIgkZVMd2Fbc@paquier.xyz
Whole thread Raw
In response to Re: Let's make PostgreSQL multi-threaded  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Mon, Jun 12, 2023 at 12:24:30PM -0700, Andres Freund wrote:
> Those points seems pretty much unrelated to the potential gains from switching
> to a threading model. The main advantages are:
>
> 1) We'd gain from being able to share state more efficiently (using normal
>    pointers) and more dynamically (not needing to pre-allocate). That'd remove
>    a good amount of complexity. As an example, consider the work we need to do
>    to ferry tuples from one process to another. Even if we just continue to
>    use shm_mq, in a threading world we could just put a pointer in the queue,
>    but have the tuple data be shared between the processes etc.
>
>    Eventually this could include removing the 1:1 connection<->process/thread
>    model. That's possible to do with processes as well, but considerably
>    harder.
>
> 2) Making context switches cheaper / sharing more resources at the OS and
>    hardware level.

Yes.  FWIW, while reading the thread, parallel workers stroke me as
the first area that would benefit from all that.  Could it be easier
to figure out the incremental pieces if working on a new node doing a
Gather based on threads, for instance?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "Tristan Partin"
Date:
Subject: Re: Meson build updates
Next
From: Nathan Bossart
Date:
Subject: Re: Atomic ops for unlogged LSN