Re: Parallel threads in query - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Parallel threads in query
Date
Msg-id 15449.1541020276@sss.pgh.pa.us
Whole thread Raw
In response to Parallel threads in query  (Darafei "Komяpa" Praliaskouski <me@komzpa.net>)
Responses Re: Parallel threads in query
List pgsql-hackers
=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?= <me@komzpa.net> writes:
> Question is, what's the best policy to allocate cores so we can play nice
> with rest of postgres?

> What I'd like to see is some function that I can call and get a number of
> threads I'm allowed to run, that will also advise rest of postgres to not
> use them, and a function to return the cores back (or do it automatically
> at the end of query). Is there an infrastructure for that?

There is not, because we do not use or support multiple threads inside
a Postgres backend, and have no intention of doing so any time soon.
There is a huge amount of non-thread-safe infrastructure there, and
if you call any of it from other than the main thread, bad things will
happen.

You might be able to make this work if the threaded stuff is kept rigidly
separate from any core Postgres code, but it'll be error-prone.

            regards, tom lane


pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Super PathKeys (Allowing sort order through precision loss functions)
Next
From: Tom Lane
Date:
Subject: Re: Should pg 11 use a lot more memory building an spgist index?