I did some testing, and the representation of tags in a hstore is more efficient than our current text[] array of alternating keys and values. For testing latter can be turned into the former with hstore(tags).
Doing this on the slim table of a planet and summing the pg_column_size gives a size of 38GB for text[] representation and 30GB for hstore. The overall size of the current slim table is 94GB for the table and 190GB for the indexes so this is about a 5% space savings.
I considered jsonb, but it is the same size as hstore.
This change would require the hstore extension for osm2pgsql databases. I do not consider this an issue because hstore is a standard part of contrib, and many databases require it already.
In addition to being more efficient, if someone did want to use our internal slim tables to query by tag, it is much easier to do so with hstore.
I did some testing, and the representation of tags in a hstore is more efficient than our current
text[]array of alternating keys and values. For testing latter can be turned into the former withhstore(tags).Doing this on the slim table of a planet and summing the
pg_column_sizegives a size of 38GB fortext[]representation and 30GB forhstore. The overall size of the current slim table is 94GB for the table and 190GB for the indexes so this is about a 5% space savings.I considered jsonb, but it is the same size as hstore.
This change would require the hstore extension for osm2pgsql databases. I do not consider this an issue because hstore is a standard part of contrib, and many databases require it already.
In addition to being more efficient, if someone did want to use our internal slim tables to query by tag, it is much easier to do so with hstore.