Re: Update statistics bug

Vickey - Looks like this query is a PDQ (Parallel Data Query) job. The 'sqlexec thread is sort of a parent thread; that's the controller and coordinator of the job, and what communicates with the user or front end. The 'scan_5.0' and 'scan_6.0' threads are (as their name implies) scan threads. These just scan through the tables and find rows that match your where clause, and pass these rows along. These rows are passed along to the 'join_xxx' and 'hjoin_xxx' threads, where the tables are joined together based (again) on the where clauses. Lastly, there's a 'group' thread in there, that takes care of your 'group by' clause. Because PDQ is turned on for this query, all of this can happen simultaneously. This will make the query run considerably faster, but it will use up many more resources. Based on the fact that there's an 'hjoin' thread (hash join), this looks like a decision support type query. You may want to check the indexing strategy against the SQL of the query to see if you can force this through an index. If that's the case, you'll dramatically reduce the resources used. If you were to turn PDQ off (set MAXPDQPRIORITY=0), this would use far fewer resources, but the query will take MUCH longer. If you e-mail me (privately, not to the list!) the full onstat -g ses <sid> output, I'll gladly try to help in a little bit more detail. As for documentation, I've yet to see a real good explanation of a lot of the -g ses output, even in the training manuals. HTH, - Thomas J. Girsch Database Systems Manager Arch Communications Group, Inc. Vickey Crouch wrote in message <34B11569.5053@swbell.net>... >NAME STATUS >sqlexec cond wait(sm_read) >group_1. cond wait(await_MC1) >join_2.0 cond_wait(await_MC2) >join_2.1 cond_wait(await_MC2) >hjoin_3. cond_wait(await_MC3) >join_4.0 cond_wait(await_MC4) >join_4.1 cond_wait(await_MC4) >scan_5.0 cond_wait(await_MC5) >scan_6.0 cond_wait(await_MC6) > >Why are all of these different threads running? What do they mean? >What is, for example, MC1? An even bigger qestion is, is there some >documentation available that REALLY explains the onstat output?