Re: Let's make PostgreSQL multi-threaded

2023-06-15 Thread James Addison
On Thu, 15 Jun 2023 at 08:12, Konstantin Knizhnik wrote: > > > > On 15.06.2023 1:23 AM, James Addison wrote: > > On Tue, 13 Jun 2023 at 07:55, Konstantin Knizhnik wrote: > > > On 12.06.2023 3:23 PM, Pavel Borisov wrote: > > Is the following true or not? > &g

Re: Let's make PostgreSQL multi-threaded

2023-06-14 Thread James Addison
On Tue, 13 Jun 2023 at 07:55, Konstantin Knizhnik wrote: > > > > On 12.06.2023 3:23 PM, Pavel Borisov wrote: > > Is the following true or not? > > > > 1. If we switch processes to threads but leave the amount of session > > local variables unchanged, there would be hardly any performance gain. >

Re: Let's make PostgreSQL multi-threaded

2023-06-14 Thread James Addison
On Wed, 14 Jun 2023 at 20:48, Robert Haas wrote: > > On Wed, Jun 14, 2023 at 3:16 PM James Addison wrote: > > I think that they're practical performance-related questions about the > > benefits of performing a technical migration that could involve > > significant deve

Re: Let's make PostgreSQL multi-threaded

2023-06-14 Thread James Addison
On Mon, 12 Jun 2023 at 20:24, Andres Freund wrote: > > Hi, > > On 2023-06-12 16:23:14 +0400, Pavel Borisov wrote: > > Is the following true or not? > > > > 1. If we switch processes to threads but leave the amount of session > > local variables unchanged, there would be hardly any performance

Re: Let's make PostgreSQL multi-threaded

2023-06-10 Thread James Addison
I don't have an objection, but I do wonder: can one (or perhaps a few) queries/workloads be provided where threading would be significantly beneficial? (some material there could help get people on-board with the idea and potentially guide many of the smaller questions that arise along the way)