Re: Postgres with pthread - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Postgres with pthread
Date
Msg-id D8C6EFAB-00A4-4658-B67A-9FB11296BF61@anarazel.de
Whole thread Raw
In response to Re: Postgres with pthread  (james <james@mansionfamily.plus.com>)
Responses Re: Postgres with pthread
Re: Postgres with pthread
List pgsql-hackers

On December 27, 2017 11:05:52 AM GMT+01:00, james <james@mansionfamily.plus.com> wrote:
> > All threads are blocked in semaphores.
>That they are blocked is inevitable - I guess the issue is that they
>are
>thrashing.
>I guess it would be necessary to separate the internals to have some
>internal queueing and effectively reduce the number of actively
>executing threads.
>In effect make the connection pooling work internally.
>
>Would it be possible to make the caches have persistent (functional)
>data structures - effectively CoW?
>
>And how easy would it be to abort if the master view had subsequently
>changed when it comes to execution?

Optimizing for this seems like a pointless exercise. If the goal is efficient processing of 100k connections the
solutionis a session / connection abstraction and a scheduler.   Optimizing for this amount of concurrency just will
addcomplexity and slowdowns for a workload that nobody will run. 

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


pgsql-hackers by date:

Previous
From: james
Date:
Subject: Re: Postgres with pthread
Next
From: Maksim Milyutin
Date:
Subject: Re: Using ProcSignal to get memory context stats from a runningbackend