in reply to Space Efficiency of Hashes

A straight SQL join statement is running horribly slow on my DB and our DBA can offer no suggestions for tuning.

Five million rows isn't that large, if the system is properly sized for it, and the database is tuned correctly. (which may be big 'if's).

I know nothing about your data, or what database you're using, so it's really hard to give specific help. (for instance, you can override Oracle's join behavior by giving hints). Even in other languages, exactly how you write your SQL can result in you doing a sort-merge join vs. a correlated join... In some situations, indexes can hurt you, and you'll want to make sure the tables are properly analyzed by the database so it knows when those times are. EXPLAIN PLAN in Oracle, and EXPLAIN in mySQL are your friends.

(I'm not going to say that your DBA hasn't already done this ... but I've worked with a few DBAs who weren't much more than an operator on a mainframe. Your database might not be tuned for this sort of operation, but that's no reason that you shouldn't be able to perform this in SQL, with a little prep work.)

Replies are listed 'Best First'.
Re^2: Space Efficiency of Hashes
by Anonymous Monk on Mar 16, 2005 at 03:40 UTC

    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.

      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.