when you note, "same setup" what does this mean?

Update performance is largely a function of the distribution key. You will see radical swings in performance like this if you are attempting to perform an update without the distribution key in the where-clause. The distribution key allows the machine to hash the key and then distribute the actual content of the update only to its designated SPU. Without it, you might see it dispatch the entire contents of the update to all the SPUs, which is why the radical swing.

Are both tables distributed on "sourceInstalledHouseholdNumber"? And if not, is the target table at least distributed on the key mentioned in the join?

Performance is found in the configuration of the data. How the data is layed out in the SPUs is the master arbiter. Tweaking and tuning the machines is the wrong answer.

While the differences in the versions can have an effect, your real problem is in attempting to update a table that is distributed on random.

Update is a key-based operation.

Think about how you would perform this update in the real world. If you have forty houses on the block, and you have ten packages to send to the

residents of the block, but the residents are scattered randomly across the houses, you would have to either send all ten packages to each house, or

you would have to call each house to determine who lived there, then send the package to the right place.

But if the houses have families by name, and you have a list of names in-hand and their home addresses, you could send each package directly to the home

address without any further work.

The Netezza machine applies power at the physics layer. Physics is driven by distribution-key coordination. If you have no distribution, you invoke a broadcast. Not

all broadcasting is bad for outbound queries, but when you want to do an update, broadcasting is bad.

I would also suggest that you put pen-to-paper and derive an insert-only model for your database. This only requires incrementally more creativity and work, but eliminates much of the data management problems you see following updates and deletes.

for example, with updates and deletes, you must eventually reclaim the space created by the operation. It will not reclaim it for you. An update operation is a full record delete/insert combination. So you take the penalty of the delete and the insert together, rather than just the insert alone. What is the penalty? A hole in your table that you will have to reclaim, because when Netezza deletes it does not remove the record, it only marks it for deletion and therefore excludes it from all queries But it still occupies space. I've seen people over time say they have only a million records in a table but the table is taking up the space of forty million records - all because forty million deletes/updates have occurred over time and the space was never reclaimed.