It certainly is. We discussed that in great detail under this related question.
It also depends on the data types of the indexed columns. An index on, say, two
integer columns is exactly as big as an index on one. Space is typically allocated in chunks of 8 bytes. For one integer (4 bytes) that's another 4 bytes of padding.
The keywords here are data alignment and
MAXALIGN: usually 4 Bytes on a 32-bit OS or 8 Bytes on a 64-bit OS. If you are not sure, check out
In such a case there is really no downside for the planner to use an index on
(a,b) - compared to an index on just
(a). And it is generally preferable for multiple queries to use the same index. The chance for it to reside in the cache already (or at least parts of it) grows when shared.
If you already maintain an index on
(a,b), then it doesn't make sense to create another index on just
(a) - unless it is substantially smaller. The same is not true for
(a). Follow the link in the first line for more on that.
On the other hand, there is a potential downside to including an additional column in the index, even if that only utilizes space otherwise wasted for padding. If the additional column is updated, the index needs an update, too. Also prevents potential HOT (Heap Only Tuple) updates on the table when this column is involved. More on HOT updates in this related answer on SO.
More on how to measure object sizes in this related answer.