Re^2: Space Efficiency of Hashes

Oh I totally agree. This code is being ported from an Oracle server running on a dual-processor PC to DB2 running on a 20+ processor, 16 GB machine and yet performance has degraded incredibly. The table definitions and indices are identical, but I don't have any access privileges on DB2 to tune things so... this is a definite second choice until they get their act together.

Comment on Re^2: Space Efficiency of Hashes

Replies are listed 'Best First'.
Re^3: Space Efficiency of Hashes by Tanktalus (Canon) on Mar 16, 2005 at 04:12 UTC
Let me guess ... and it's the same (Oracle) DBA who is helping tune your DB2 system. Different RDBMS, different magnitude of hardware ... same approach? If I were talking to the DBA, I would suggest asking IBM for help in tuning the migration. If I were the DBA, I would have tried to get that tuning in before plunking down the money. However, as neither case applies, the best you likely could do is suggest to the DBA that s/he talks to IBM, and suggest it in such a way that it sounds like the DBA's idea.	[reply]
Re^4: Space Efficiency of Hashes by terra incognita (Pilgrim) on Mar 16, 2005 at 16:20 UTC
Some tuning suggestions for DB2 can be found at http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0404mcarthur/index.html These include suggestions for tuning your SQL Statement so you do not need to rely on your DBA to do them. One improvement I have used in the past is the "SELECT … FOR READ ONLY" optimization. This will allow DB2 to speed up the statement execution in some cases.	[reply]


Just another Perl shrine
	PerlMonks