Database Tasks that Run on the Parsing Engine - blog entry by carrie

Most of us are aware of AMP worker tasks, and some of us are even obsessive about not running out of this finite resource.  But that’s on the AMP.  What about the tasks supporting user work on the parsing engine (PE)?  Should we be just as vigilant about what’s happening with tasks at the PE level?

Not really.  Here’s why.

Each parsing engine has a pool of tasks called SQLDriver tasks that perform PE activities.  There are 128 of these tasks per PE, and similar to AMP worker tasks (AWT), they are initiated at startup time and stay active until the database shuts down.

You do not need to be concerned about running out of SQLDriver tasks, as only one will ever be used by a single session, and a PE is limited to 120 sessions.  There are a few additional SQLDriver tasks (8 more than the number of sessions allowed) for special internal purposes.  I am not aware of any issues involved in running out of SQLDriver tasks, so you can cross them off your monitoring list.

There a couple of interesting differences between AWTs and SQLDriver tasks I want to share with you:  

1. When a transaction or a request is aborted due to an error or a user-generated abort, any active AWT running on behalf of that transaction or request will get terminated. Subsequently, a new AMP worker task will then be started to replace the one that was killed.  However, at any point in time, there could be fewer AWTs running on an AMP than the system setting specifies.  SQLDriver tasks, in contrast, never get terminated until a database restart.
2. A session has access to only one SQLDriver task at a time.  All CPU work performed on the PE for one session and all of its requests is single-threaded through that one task.  This is different from AMP work, where all-AMP query steps have at least one AMP worker task active on its behalf for each AMP in the configuration.   

When you look at AMP CPU seconds for a request you are seeing an accumulation across all AMPs.  Because AWTs may be accumulating time on different CPUs in parallel, the wall-clock time for getting the AMP work could be less than the reported CPU seconds. 

On the other hand, PE CPU seconds usually take a longer amount of wall-clock time to consume than their reported CPU seconds because one SQLDriver task on a single CPU on one node is doing all the PE work.