The fact is that this question cannot be answered as such, so I will reframe it and answer as reframed.
The basic problem is that the database size will depend entirely on implementation details of the db. It could be the same size, could be more, could be less. We can't say. Additionally it may depend on how much repetition is avoided using one approach or the other.
At any rate it is exactly the wrong question to ask here. The right question is how your data relates to eachother. You basically have three options:
Second table with 1000000 rows. Use this if there are normalization issues or if you need to break this off for table space reasons. It may increase the size of the db because of join conditions.
New column. Use this if the data does not belong in the same column of the other table due to semantic reasons, but is functionally dependent on the data in the existing rows.
New rows. Use this if the data belongs in the existing rows based on the internal semantics of the data.
Note that table size is not your biggest concern. You can probably use indexes to address them but 1-2 million rows is still way too small to worry about size-wise in this way.