Even if your scenario is valid, perhaps you could reduce the depth of nesting without changing the query semantics? Or rearrange the order of things? e.g. cond1 AND (cond2 AND ( cond3 AND cond4 ) could become ( cond1 AND cond2 ) AND ( cond3 AND cond4 ) or ( ( cond1 AND cond2 ) AND cond3 ) AND cond4 and that might not get to such a full stack. Eyal On 12/19/17 4:57 PM, Sharma, Sreejith wrote:
All,
I have a valid scenario where our application generates a SQL which is around 4.4MB and contains 75K of combination of AND and OR operators. This SQL fails with “SELECT: too many nested operators” error while executing this SQL.
While I went through the code, I noticed any thread size above THREAD_STACK_SIZE - 16 * 1024 is getting aborted. Is there any possibility that we can change this? Any reason why it’s set to 16MB? As server our server has enough memory and storage and we need to understand if this can be handled in code or via parameter as this is valid scenario. Also, we can’t split the SQL too.
Regards,
Sreejith
_______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list