Re: Parallel Seq Scan
От | Jim Nasby |
---|---|
Тема | Re: Parallel Seq Scan |
Дата | |
Msg-id | 54B38308.9080507@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Parallel Seq Scan (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On 1/11/15 3:57 PM, Robert Haas wrote: > On Sun, Jan 11, 2015 at 5:27 AM, Stephen Frost <sfrost@snowman.net> wrote: >> * Robert Haas (robertmhaas@gmail.com) wrote: >>> On Thu, Jan 8, 2015 at 2:46 PM, Stephen Frost <sfrost@snowman.net> wrote: >>>> Yeah, if we come up with a plan for X workers and end up not being able >>>> to spawn that many then I could see that being worth a warning or notice >>>> or something. Not sure what EXPLAIN has to do anything with it.. >>> >>> That seems mighty odd to me. If there are 8 background worker >>> processes available, and you allow each session to use at most 4, then >>> when there are >2 sessions trying to do parallelism at the same time, >>> they might not all get their workers. Emitting a notice for that >>> seems like it would be awfully chatty. >> >> Yeah, agreed, it could get quite noisy. Did you have another thought >> for how to address the concern raised? Specifically, that you might not >> get as many workers as you thought you would? > > I'm not sure why that's a condition in need of special reporting. The case raised before (that I think is valid) is: what if you have a query that is massively parallel. You expect it toget 60 cores on the server and take 10 minutes. Instead it gets 10 and takes an hour (or worse, 1 and takes 10 hours). Maybe it's not worth dealing with that in the first version, but I expect it will come up very quickly. We better make surewe're not painting ourselves in a corner. -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: