In short: best not do it. A better solution would be to use something like BCrypt. You can use a higher number of rounds to ensure that attacking that is computationally infeasible.
As for added or diminished security: it depends on whether the hashes leak. In both cases the difference in security isn't so great, so that all that's happening is that you're burning CPU cycles that might have been used for bcrypt.
If the hashes aren't leaked to the attacker, then your system is negligibly more secure, because even if by any chance a hash collision was found, it is improbable in the extreme that the collision would extend to the alternate hashes. So this solution defends against collisions. But since the chance of a collision is very small in the first place, making it even smaller has an advantages-over-costs ratio which is practically zero.
If the hashes do leak to the attacker, then he has that many more hashes to attack. The system becomes proportionally less secure, if discovering the source of a variant hash gives hints on what the real password might be. For that reason, the variant hash ought to be itself a hash (and just in case, a binary hash, and obtained by a different algorithm). Then the attacker has no way of knowing what he has found. The security of the system stays the same, and we just burned some CPU cycles.
UPDATE: let's assume the hashing algorithm used is something
ridiculous (and fast) like MD5, and that the attacker has gained
access to the database > through whatever means.
Okay, in that case our hypothetical attacker can try and mount a preimage attack or collision attack, or he might just google them all. And he finds, say,
f7eedbcbee1453935bc9b36870810f58 on Google.
The probability of finding a hash on Google is loosely (since we're dealing with trivial modifications, but modifications nonetheless) proportional to the number of hashes to attack.
f7eedbcbee1453935bc9b36870810f58 is not the hash of the "real" password. However, at that point the real password (for which he has a hash to confirm it having being indeed found) is just milliseconds away.
Salting and/or manipulating the hashes changes little. What it does is, increase the security X-fold. But having four hashes instead of one is still roughly, say, up to four times less secure. Salting just makes it so instead of having a fourth of a small number, you have a fourth of a huge number. By using no extra hashes, you would still increase the overall security.