| From: | Darafei "Komяpa" Praliaskouski <me(at)komzpa(dot)net> |
|---|---|
| To: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Parallel threads in query |
| Date: | 2018-10-31 19:07:43 |
| Message-ID: | CAC8Q8tKNO3pQguAEL8mXw8RdUMZ95T+BwTEozybOqTPKConEiA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
I've tried porting some of PostGIS algorithms to utilize multiple cores via
OpenMP to return faster.
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?
--
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2018-10-31 21:07:39 | Re: Super PathKeys (Allowing sort order through precision loss functions) |
| Previous Message | Tom Lane | 2018-10-31 18:52:29 | Re: Super PathKeys (Allowing sort order through precision loss functions) |