Hey David, sorry about the delay.
What you’re seeing is expected - those “-threads” settings do concurrency control. They make a difference when you have multiple users running queries at the same time. If only one query is running at a time, you won’t see a difference from changing those.
So, like I mentioned, a query will typically use 1 core per instance. So changing the number of instances gives you the most control. Unfortunately, if you don’t have the Enterprise Edition, then changing the number of instances takes longer to do. The best way to do it with the Community Edition is to do a parallel opaque save, then re-load the files into bigger or smaller cluster. https://paradigm4.atlassian.net/wiki/spaces/scidb/pages/241041478/Backing+Up+Restoring+Arrays
With the elastic resource groups plugin (link I gave above), you can somewhat “fake it out.” If you have 16 instances you can say “create an array that lives on instances 0,1,2,3 only”. Then, initially, queries against that array will use only those four instances. So you’d expect aggregates and filters to slow down in proportion. But then if you do big sorts, redimensions or joins, SciDB is liable to re-scatter the data across all 16 instances during the query.
Hope it helps!