The owasp link you provided explains the two goals of using a salt:
1) Not being able to tell two passwords are identical based on the resulting hash. The e-mail is unique per user, so even if a bunch of users have "password" as their password, the hashes will all be different. Yes, if a user changes their password from "password" to "password" then the hash remains the same, but this is a very minor problem.
2) Prevent rainbow attacks. The constant part of the salt is enough to demand a site-specific rainbow table, and the e-mail takes this even further to a site + e-mail combo. Thus rainbow attacks would only have value in targeted attacks against a known site constant & e-mail combo. Once a good table is complete, it won't matter if the user changes their password.
Using a unique random salt would solve these two issues, however they can also be solved by adding a simple timestamp of the password's initial hashing time to the salt.
Several implementations utilise a Salt + Papper (unique per user value and single per site value). A Pepper is particularly useful when it is NOT stored in the database (e.g. stored in an environmental variable or even code). That way if someone steals your database via SQL Injection or a database backup file, they'd have to break the Pepper to recover passwords.
Peppers only make sense when they're almost "free" to implement. A slow hashing scheme is the most important thing, then unique salting, and finally a pepper last (since a pepper adds the least security wise).
(I'm not arguing it's "too horrible", but I am saying that it's worse than other schemes that aren't significantly more burdensome.)
Each record should have a unique, random salt. You then store salt:hash(salt+password).
There are numerous guides on how to do this properly, for example https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet