Re: Let's make PostgreSQL multi-threaded

On Wed, 14 Jun 2023 at 20:48, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Wed, Jun 14, 2023 at 3:16 PM James Addison <jay(at)jp-hosting(dot)net> wrote:
> > I think that they're practical performance-related questions about the
> > benefits of performing a technical migration that could involve
> > significant development time, take years to complete, and uncover
> > problems that cause reliability issues for a stable, proven database
> > management system.
>
> I don't. I think they're reflecting confusion about what the actual,
> practical path forward is.

Ok. My concern is that the balance between the downstream ecosystem
impact (people and processes that use PIDs to identify, monitor and
manage query and background processes, for example) compared to the
benefits (performance improvement for some -- but what kind of? --
workloads) seems unclear, and if it's unclear, it's less likely to be
compelling.

Pavel's message and questions seem to poke at some of the potential
limitations of the performance improvements, and Andres' response
mentions reduced complexity and reduced context-switching. Elsewhere
I also see that TLB (translation lookaside buffer?) lookups in
particular should see improvements. Those are good, but somewhat
unquantified.

The benefits are less of an immediate concern if there's going to be a
migration/transition phase where both the process model and the thread
model are available. But again, if the benefits of the threading
model aren't clear, people are unlikely to want to switch, and I don't
think that the cost for people and systems to migrate from tooling and
methods built around processes will be zero. That could lead to a bad
outcome, where the codebase includes both models and yet is unable to
plan to simplify to one.