UDF & TDWM

Does UDF can be controled by TDWM?

 

 

UDFs are database objects that can extend the capability of normal SQL within the database. Once compiled, a UDF can be referenced in SQL statements for activities such as enforcing business rules or aiding in the transformation of data.
I’ve found a couple of things about UDFs that are specific to Teradata Active System Management:
A step with a UDF will show zero estimated processing time, which means classification based on estimated processing time might not produce the intended results.
While the UDF is executing, exception handling (or query milestones) is unaware of the accumulating CPU; however, after the UDF completes its processing for each row, the resource usage is visible and usable for exception handling.
A UDF will update the transaction-in-process (TIP) table on each AMP after the UDF has completed its processing on each row. As it finishes its work for a given row, the UDF makes an internal application programming interface (API) call in order to keep a running tally of CPU and I/O. This means that if each row in an answer set uses a second of CPU time while executing a UDF, that second of time will be attributed to the query and will be seen by workload management when the UDF relinquishes control for that row.
If the UDF is spending a lot of CPU time on one row, that time will not be visible until the UDF relinquishes control of the row and updates the internal database structures. So if a UDF spent an hour processing one row, or if the transaction was caught in an internal loop, workload management would not be able to detect the CPU usage until the base SQL query regains control of that row.
For queries that have UDFs with looping characteristics, you could use query banding to point them to specific workloads that run at a lower priority. You could also set up special views for queries with UDFs and classify those views to specific workloads.