Does a salted password hash reveal info about the password?

Assume a password is hashed with a secure salt, e.g. hash = sha256(password+salt). If the hash and the salt are made public, an attacker can perform an attack by running possible password candidates through the hash function to try and find the correct password eventually. The assumption here is that if the hash function yields the correct output then it was the correct input, and this is often true for collision resistant hash functions.

But one could intentionally truncate the output to create more collisions, e.g. hash = sha256(password+salt) modulo 1000.

What information could this truncated hash reveal about the password? What kind of attacks could possible if it was made public?

Edit:
I did not mean that the server should use only a truncated hash for authentication. I was thinking purely about the security implications of a truncated hash being made public. My idea was that this could possibly be used as part of a challenge-response interchange to check that the client is "likely" in possession of the correct password before proceeding with the rest of the interchange.

If what you're trying to compare are the two scenarios:

1. Server uses regular hash with salt, and attacker obtains both
2. Server uses truncated hash with salt, and attacker obtains both

Then obviously the attacker has an easier job in Scenario #2 because for a truncated hash computed via the same algorithm, he will find a collision faster (If those are different algorithms, the output hash being shorter doesn't necessarily imply that the hash is faster to compute).

Remember that the attacker doesn't have to guess the correct password, he only needs to calculate a password that matches whatever hash value the server stores. I'm making the reasonable assumption that the server stores only the hash, not the password itself, otherwise storing a hash is rather pointless (at least as far as security goes).

Now, if an attacker only has access to the truncated hash but not the salt, then obviously it makes a big difference exactly how you perform the truncation. The "modulo 1000" example you gave for example will yield any hash trivially breakable, because the hash value will be in the range $0-999$ which is an exceedingly small search space. Of course, here he doesn't know the salt value, so he has no way to precompute possible hashes on his own, yet this is still an extremely insecure way to compute a hash, because of the ease of performing an exhaustive search attack directly on the server. However, if it is a reasonable hash function truncated to a reasonable size, for example: truncate(sha512(password||salt), 256) then probably the attacker isn't much better off without access to the salt value.

In general, I don't see any security benefit in truncating a hash for this specific use case. There are interesting security-related use cases where truncating a hash can be useful: if you want to create some kind of data equivocation, e.g. make it difficult for an adversary to ascertain that a hash value belongs to a certain object and not another.

But again, since when talking about password hashes, the correctness of the password sent to the server in general doesn't matter, but only it (in combination with the salt, if used) having a matching hash value, I don't see how that can have any security benefit.