Comments on: JOIN_BY_SQL Revisited

By: David

David — Mon, 15 Dec 2008 13:39:11 +0000

This seems to work well in Teradata but I saw Netezza query performance suffer. It was better to there to have the default behavior send the smaller chucks of sql to this engine.

By: Dave Rathbun

Dave Rathbun — Wed, 23 Jan 2008 17:31:56 +0000

Hi, Chris, and thanks for your comment. Prior to JOIN_BY_SQL being available you might see two combination operations in the query panel: JOIN or SYNCHRONIZE. The JOIN_BY_SQL technique only works for JOIN operations. Anything that requires a SYNCHRONIZE operation is still done on the client.

At least that is what my memory is telling me; I did not try to retest that prior to responding to your question.

By: Chris Cammers

Chris Cammers — Tue, 22 Jan 2008 18:35:15 +0000

When you use Join_By_SQL what happens when the queries do not have matching dimensions. Does this still push the work down to the database?

By: Dave Rathbun

Dave Rathbun — Fri, 18 Jan 2008 03:38:50 +0000

The big change for us was our individual data provider count went from 6 down to 3 after we pivoted the data so CY and PY data were on the same row. We also reduced the row count for each data provider by providing more restrictive prompts. So the number of rows returned by the individual data providers has been reduced substantially.

I believe that if we were still running larger data providers (with tens of thousands of rows) that the report performance would still be better with JOIN_BY_SQL turned on. That despite the way Teradata would have treated them.

Your points about Crystal are perfectly valid, of course. In this project we’re using only Webi to generate reports so that was not a constraint for us.

By: Andreas

Andreas — Thu, 17 Jan 2008 19:48:23 +0000

Actually, for people using Crystal it is a magical bullet as it allows queries in Crystal against a universe using multiple universe contexts and therefore SQL statements. Crystal at this time cannot handle queries against a universe that generates multiple SQL statements otherwise.

I used this setting against Teradata using Webi for up to 10 SQL statements (caused by 10 fact tables, multiple star schema), but I was not able to do a sufficient analysis regarding perfromance with real data volumes, because of resource restraints.

In any case the JOIN_BY_SQL will reduce the load on the BOE server, as only one microcube will be returned, instead of multiple ones. If this benefit outweighs the additional load put on the DBMS server needs to be evaluated on a case by case basis (just as you did, Dave)