From: | Paul Ramsey <pramsey(at)cleverelephant(dot)ca> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Darafei Praliaskouski <me(at)komzpa(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Parallel threads in query |
Date: | 2018-11-01 17:10:33 |
Message-ID: | CACowWR0n_2G2ta6Edn6LSYZSXgVD_N6aiJEBaROnWVc_8mABbA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 31, 2018 at 2:11 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> =?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?= <me(at)komzpa(dot)net>
> writes:
> > Question is, what's the best policy to allocate cores so we can play nice
> > with rest of postgres?
>
> 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.
>
As a practical matter though, if we're multi-threading a heavy PostGIS
function, presumably simply grabbing *every* core is not a recommended or
friendly practice. My finger-in-the-wind guess would be that the value
of max_parallel_workers_per_gather would be the most reasonable value to
use to limit the number of cores a parallel PostGIS function should use.
Does that make sense?
P
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-11-01 17:15:27 | Re: Parallel threads in query |
Previous Message | Robert Haas | 2018-11-01 17:01:55 | Re: New vacuum option to do only freezing |