It certainly is. We discussed that in great detail under this related question:
Space is allocated in multiples of
MAXALIGN, which is typically 8 bytes on a 64-bit OS or (less common) 4 bytes on a 32-bit OS. If you are not sure, check
pg_controldata. It also depends on data types of indexed columns (some require alignment padding) and actual content.
An index on, say, two
integer columns typically ends up to be exactly as big as an index on one. For just one
integer (4 bytes) another 4 bytes of alignment padding are added.
In such a case there is really no downside for the query 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 cache already (or 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 additional columns in an index, even if that only uses space otherwise lost to alignment padding. If an 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:
How to measure object sizes: