On Wed, 14 Jun 2023 at 20:48, Robert Haas <robertmh...@gmail.com> wrote: > > On Wed, Jun 14, 2023 at 3:16 PM James Addison <j...@jp-hosting.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.
