Doubtful but not sure; Boolean isn't that large a structure anyway...
I'm not sure you'd want to introduce tri-value logic in this case anyway. If you know something is false why would you claim that you don't know what the value? Data should first and foremost be accurate and precise. In this case if you make the change then anyone else looking at or using the data needs to learn a very non-standard way of dealing with booleans.
If fact I can imagine few cases where a Boolean field would be null and even if they do not often it is sufficient to assume false.
What you might consider is whether a partial index for true values is warranted. This will add some space but make queries go faster. If you already index the column then a partial index alternative will make the index smaller while still being useful. A full index is not that useful since a false condition will likely use a table scan anyway.
Physical space for data should be a minor concern. The more pressing concern is efficient retrieval of that data. Using null instead of false, even if it were to save space, is not going to make a significant dent, and what savings you would get would be outweighed by the unusual data and how you'd go about querying it. You can't say, for instance, "ispresent = ?" and replace the ? With true/false anymore.
So while not a dumb question per se if you are considering this for anything more than curiosity I would humbly suggest looking at other area to improve performance and reduce size. Though, as mentioned, physical storage is fairly inexpensive anyway. If you are generating enough data to make storage a concern you should be able to justify the expense of getting more storage.
David J.
Possibly a dumb question but there isn't much about this.
I have some BOOLEAN columns. 90% of the cases of the columns is FALSE. Do I save disk space by having them as NULL instead of FALSE? So my application would have conditional code for NULL and TRUE, instead of FALSE and TRUE.
Thanks...
