Oracle queries may translate syntactically and functionally but not really with the same performance profile. The SMP/RDBMS is not the same architecture as Netezza.
Those who spend time directly porting from an RDBMS into Netezza with one-for-one query/stored-proc etc have not only created a mess, but lost an important opportunity to leverage Netezza's power in context of massively parallel. Often when people build structures and queries in an SMP/RDBMS they are constrained to use index structures and table constructs that align with the RDBMS constraints or weaknesses. Those same constraints and weaknesses do not exist in Netezza, so porting one from the other "as is" is a lot like moving from one house to another and taking all the furniture, trash and even the dust on the floor from the old house to the new, and upon arriving failing to use the jacuzzi, microwave or fireplaces because they didn't exist in the old house. it is also virtually guaranteed that as the old system started running out of power, engineers swarmed to prop it up. We don't want to take any of those performance props with us, either.
That's a long introduction to a short point - analyze what you are trying to accomplish and then shape the data and the queries to make it go. Ignore the performance props from the old system. Configure the Netezza machine to fulfill (one or more) functional mission(s), not just "do what the old system did".
A simple example of this that you will see talked about, is taking a common cursor based query (or series of queries) that perform multiple rules on one-row-at-a-time. Most stored procs in an RDBMS are one-row-at-a-time processes. There is no such thing as one-row-at-a-time in Netezza. In one case, a single process applied four rules to each of 3500 counterparties, costing 30 seconds or more for each and running for hours. A Netezza version of this would "lay the process on its side" and run all 3500 counterparties through one rule, then the next etc. What used to take hours now takes less than a minute.
What this means, is that performance tuning IS NOT IN THE QUERY. In the SMP RDBMS we are constrained to shape the general-purpose hardware's activity by using query tricks. But when you submit a query to Netezza, it is immediately snipped apart and dispatched to leverage the machine's physics. So in a Netezza machine, you can really pull your hair out trying to tweak and tune a query to get just a little more. But in the end, you are much better off in distributing the data, leveraging zone maps and other performance-model features than fiddling with the query. The question you have asked is useful in context of fixing the data so that the query runs faster. It is rarely suitable to spend a lot of time on the the query itself.
This means all of your SQL should be configured for VLDB, not just a common SMP/RDBMS implementation. And avoid those 100-page SQL statements. Netezza has set you free.
