How much bigger does a precomputed lookup table get when salt is added?
There are a couple of different things going on here, and you need to define your problem more clearly. 

For starters, let's just look at a simple case where what is being stored in a database (for each user) is either $H(pw)$ or $s, H(s, pw)$ where $H$ is a hash function, $pw \in \{1, \ldots, N\}$ is a password, and $s \in \{0,1\}^\ell$ is a salt.

To attack a single user without a salt, the attacker can pre-compute $H(pw)$ for all possible values of $pw$ yielding a table of size $N$. Without knowing the salt, however, the attacker has to compute $H(s, pw)$ for all possible salts as well, thus requiring a table of size $N \cdot 2^\ell$. On the other hand, if the attacker does no pre-computation but instead just waits until it compromises the database and then obtains $s^*, H(s^*, pw)$, then we are back to the previous case where the attacker just has to compute $N$ values of $H(s^*, pw)$ to learn the password. 

Thus, in the single-user case, the salt increases the attacker's off-line computation but does not increase the on-line computation needed.

Before continuing, let me note also that (in the case without the salt) the attacker can use  to obtain various time-space tradeoffs. Use of salts makes rainbow tables less effective as well.

Salts also help, in a somewhat orthogonal way, in the multi-user setting. To see this, note that if the attacker got the database of hashed passwords in the unsalted case, then using $N$ work he gets the passwords of all users. But in the salted case, assuming each of $M$ users is assigned a different salt, the attacker must do $M \cdot N$ work to recover all passwords.