Comments on: Want To Crash Teradata? Give It Some LOV…

By: JK

JK — Wed, 27 Oct 2010 20:51:10 +0000

Dave,
Being an old ‘Teradactyl’, your article was interesting. The DISTINCT option (within TD) internally processes the data differently than the GROUP BY and in the process does an internal sort before it removes duplicate values. With the GROUP BY, it will remove all the duplicats on each unit of parallelism before further processing and the result set is not in any order – as per Relational Theory;-) I know from a BI tool perspective this might seem to be a ‘neat feature’ but in terms of an underlying DBMS, it should not be taken for granted – i.e. a sorted order result set, unless it is specified in an ORDR BY clause. It appears in TD13 that Teradata finally ‘fixed’ the differences in processing and used the internal logic of the GROUP BY. B-T-B, GROUP BY is ‘usually’ a lot faster internally and the final sort has a very low overhead as that is done in its parallelism result processiing logic. So if you are on earlier releases, the GROUP BY will generally be faster – BUT – you must use the ORDER BY if you want a sorted LOV!

P.S. – beware of using ‘internal TD option settings’ that support a previous release functionality – they tend to be dropped/removed at later dates (FYI)

By: Dave Rathbun

Dave Rathbun — Thu, 25 Mar 2010 03:46:18 +0000

Hi, Boris, and thanks for your question. I understand why you asked but I can tell you that the BOXI version is of no consequence as we were able to cause the exact same issue by running the SQL via SQL Assistant. The major version for Teradata was 13; I don’t know what fix level we were using at the time.

By: Boris

Boris — Wed, 24 Mar 2010 20:52:09 +0000

Dave — interesting problem. Can you please post the exact system information:
DBS version (including e-fix) and OS
ODBC version and OS
BOXI version and OS
This may help everyone!

By: Dave Rathbun

Dave Rathbun — Fri, 12 Mar 2010 23:15:12 +0000

Hi, Kuldeep, thank you for your question. To this point in my career I have never managed to work with Netezza. Given that, I don’t expect to write much if anything about it.

By: Kuldeep

Kuldeep — Fri, 12 Mar 2010 10:28:54 +0000

Dave, Just wanted to know if you ever tried connecting BO to Netezza, If yes Do you plan to write on this topic.

By: Dave Rathbun

Dave Rathbun — Thu, 04 Mar 2010 00:25:35 +0000

We have run into a snag, of course. Some of the LOV definitions in another universe use the ability to “sort by” an object that does not exist in the select clause. This results in invalid SQL once the distinct is removed and the group by is added because the additional column does not show up in the group by clause…

No solution yet.

By: Dave Rathbun

Dave Rathbun — Mon, 01 Mar 2010 16:50:58 +0000

Thani, welcome and thank you for your comment. The parameter does, in fact, change the behavior of the “retrieve duplicate rows” option. It will also use a GROUP BY rather than a DISTINCT. The net result should be the same.

By: Dave Rathbun

Dave Rathbun — Mon, 01 Mar 2010 16:48:23 +0000

I am not aware of a method to exclude any LOV from this sort parameter.

By: Yoav

Yoav — Mon, 01 Mar 2010 08:10:53 +0000

Thanks for the clarification,

The parameter will be global and you can’t exclude a specific LOV object out of it, right ?

Yoav

By: Thani

Thani — Mon, 01 Mar 2010 06:09:13 +0000

Hi Dave,

By changing this Universe parameter DISTINCT=GROUPBY, will this not affect the report queries as well or just to LOV query.
And how does the “Retrieve duplicate rows” WebI property will work by un-checking it?

Thanks.