On Tue, Jan 20, 2015 at 10:59 PM, Thom Brown <t...@linux.com> wrote: > > On 20 January 2015 at 14:29, Amit Kapila <amit.kapil...@gmail.com> wrote: >> >> Note - I have yet to handle the new node types introduced at some >> of the places and need to verify prepared queries and some other >> things, however I think it will be good if I can get some feedback >> at current stage. > > > I'm getting an issue: > > > > # set parallel_seqscan_degree = 10; > SET > Time: 0.219 ms > > ➤ psql://thom@[local]:5488/pgbench > > > ➤ psql://thom@[local]:5488/pgbench > > # explain analyse select c1 from t1; > > > So setting parallel_seqscan_degree above max_worker_processes causes the CPU to max out, and the query never returns, or at least not after waiting 2 minutes. Shouldn't it have a ceiling of max_worker_processes? >
Yes, it should behave that way, but this is not handled in patch as still we have to decide on what is the best execution strategy (block-by-block or fixed chunks for different workers) and based on that I can handle this scenario in patch. I could return an error for such a scenario or do some work to handle it seamlessly, but it seems to me that I have to rework on the same if we select different approach for doing execution than used in patch, so I am waiting for that to get decided. I am planing to work on getting the performance data for both the approaches, so that we can decide which is better way to go-ahead. > The original test I performed where I was getting OOM errors now appears to be fine: > Thanks for confirming the same. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com