Question

I am currently trying to optimize some bobj reports where our backend is Teradata. The Teradata optimizer seems very finicky and I was wondering if anyone has come up with a solution or a workaround to get the optimizer to treat likes in a similar regard to equals.

My issue is that we allow the user to input one of two methods:
 1. Enter the Number:
    or
 2. Enter a Number like:

Option one performs like a dream while option two is dragging our query times from 6 seconds to 2 minutes.

In addition to this; does anyone know of any good articles, discussions, vidoes, etc.. on optimizing SQL statements for the teradata optimizer?

Answer 1

Because the column is defined as a VARCHAR and you are using the LIKE operator you eliminate the possibility of using the PI for single AMP access. Remember, the primary indexes first job is distributing the data across the AMPs in the system. Because you are using the LIKE operator against the PI the optimizer must perform an ‘all AMP’ operation to satisfy the LIKE operator.

WHERE MyPIColumn LIKE '123%'

The hashing of values starting with 123 can and will end up on multiple AMPs.

WHERE MyPIColum = '123'

The hashing of 123 will place every single record on the same AMP. Querying for ‘123’ will always be a single AMP operation.

Statistics on this may help with row estimates but will likely not eliminate the ‘all AMP’ operation.

1. Is this a Unique PI or Non-Unique PI?
2. Why was the data type chosen to be character over numeric? Although GT(E) or LT(E) would likely result in the same ‘All-AMP’ operation’.
3. Is this PI shared by other tables in
   the model to facilitate AMP local
   join strategies?