Re: Parallel threads in query

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: Parallel threads in query
Дата
Msg-id a408c195-904e-72b2-085f-8691882cafc6@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: Parallel threads in query  (Andres Freund <andres@anarazel.de>)
Ответы Re: Parallel threads in query  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 11/01/2018 07:50 PM, Andres Freund wrote:
> Hi,
> 
> On 2018-11-01 19:44:54 +0100, Tomas Vondra wrote:
>> On 11/01/2018 07:40 PM, Andres Freund wrote:
>>> On 2018-11-01 19:33:39 +0100, Tomas Vondra wrote:
>>>> In theory, simulating such global limit should be possible using a bit
>>>> of shared memory for the current total, per-process counter and probably
>>>> some simple abort handling (say, just like contrib/openssl does using
>>>> ResourceOwner).
>>>
>>> Right.  I don't think you even need something resowner like, given that
>>> anything using threads better make it absolutely absolutely impossible
>>> that an error can escape.
>>>
>>
>> True. Still, I wonder if the process can die in a way that would fail to
>> update the counter.
> 
> You'd better make that case a panic restart.
> 
> 
>>>> A better solution might be to start a bgworker managing a connection
>>>> pool and forward the requests to it using IPC (and enforce the thread
>>>> count limit there).
>>>
>>> That doesn't really seem feasible for cases like this - after all, you'd
>>> only use threads to work on individual rows if you wanted to parallelize
>>> relatively granular per-row work or such. Adding cross-process IPC seems
>>> like it'd make that perform badly.
>>>
>>
>> I think that very much depends on how expensive the tasks handled by the
>> threads are. It may still be cheaper than a reasonable IPC, and if you
>> don't create/destroy threads, that also saves quite a bit of time.
> 
> I'm not following. How can you have a pool *and* threads? Those seem to
> be contradictory in PG's architecture? You need full blown IPC with your
> proposal afaict?
> 

My suggestion was to create a bgworker, which would then internally
allocate and manage a pool of threads. It could then open some sort of
IPC (say, as dumb as unix socket). The backends could could then send
requests to it, and it would respond to them. Not sure why/how would
this contradict PG's architecture?

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Parallel threads in query
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Parallel threads in query