I think you make be confusing a couple of concepts, and are asking specifically about password hashing, correct?
Password hashing, when done correctly, introduces a work factor, meaning that it takes some time to compute a hash, not strictly that a "pause" as you describe it, in involved though it does result in the end user perceiving some delay, which could be interpreted the same way.
One additional correction of note: A hash is one-way. There is no opportunity for decryption. So, if you have a hash of a password, and want to figure out what password was used to create that hash, the way that you do it is to use the same hash function, and to submit candidate passwords, and compare the resulting hash to the hash that you have, to see if they match. This is what websites (for instance) typcially do. In very simple terms, when you create an account, you're asked to provide a password, which is hashed, and the hash is stored. When you come back to log in again, you enter your password again, the website hashed what you have given it, and compares that to the hash it has stored. If they match, you're authenticated. If not, you're asked to try again.
So, the problem with a simple hash function is that its fairly easy to create the hashes of many candidate passwords very very quickly. So when the attacker steals a password hash from a database, he can then create hashes from a dictionary of possible passwords and compare the resulting hashes to the stolen hash to figure out what the password is at a staggering pace. For many common hash functions, he can try literally billions of possible passwords each second.
The fix for this, which I think you're alluding to in your questions, is the work factor that I mentioned, which is generally implemented as iterations. So when a password is submitted for hashing, it isn't hashed once, but 10,000 times, or 100,000 times, or 1,000,000 times. This means that when an attacker steals this hash, he too has to hash each of his candidate passwords just as many times in order to figure out if candidate is in fact correct. So now you've limited his possible tries from billions per second, to billions divided by 10,000, or divided by 100,000, or by 1,000,000. Much more expensive for him, and much less likely that he'll get far enough down his list of possible password to find the actual password.
In practice it's a bit more complicated that this. You have to factor in details such as salts, computational hardness vs memory hardness, and other such variables, but in general, at a high level,
this is mechanism by which make attacking password hashes difficult.