<p>I'm not convinced that this is a desirable change. Yes, having the whole address as one <code>hstore</code> value is probably nicer to pass around, but is this comfort worth the cost?<br>
I've spent some time looking into the innards of Nominatim and reducing its storage requirements and cache footprint by choosing smaller types and playing "column Tetris". These changes had a nice effect on freshly loaded, indexed, and VACUUM FULLed extracts of Germany, Switzerland, and Italy:</p>
<table>
<thead>
<tr>
<th>table</th>
<th>original</th>
<th>tetris</th>
<th>tetris + hstore-address</th>
</tr>
</thead>
<tbody>
<tr>
<td>place</td>
<td>8522 MB</td>
<td>8310 MB</td>
<td>9367 MB</td>
</tr>
<tr>
<td>placex</td>
<td>16693 MB</td>
<td>15519 MB</td>
<td>16757 MB</td>
</tr></tbody></table>
<p>But, as you can see the space wasted by using <code>hstore</code> for address outweighs my savings.<br>
An <code>hstore</code> uses 1 + 4 + 2×N×4 + size(keys) + size(values) (+3 (if more than 63)) bytes to store N key/value pairs. This sums up to 23 wasted bytes for each housenumber alone. Whereas adding an additional column just takes one bit (in the null-map) + size(value) if not NULL (when properly aligned).</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/openstreetmap/osm2pgsql/pull/737#issuecomment-294485823">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AD2-7qAWbXkFjDz2fc4rKzCtSdXYuzdeks5rw2mEgaJpZM4M3wS8">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AD2-7ipnbIwOmJlU7NNHDoATsvQ7HkQLks5rw2mEgaJpZM4M3wS8.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/openstreetmap/osm2pgsql/pull/737#issuecomment-294485823"></link>
  <meta itemprop="name" content="View Pull Request"></meta>
</div>
<meta itemprop="description" content="View this Pull Request on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/openstreetmap/osm2pgsql","title":"openstreetmap/osm2pgsql","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/openstreetmap/osm2pgsql"}},"updates":{"snippets":[{"icon":"PERSON","message":"@roques in #737: I'm not convinced that this is a desirable change. Yes, having the whole address as one `hstore` value is probably nicer to pass around, but is this comfort worth the cost?\r\nI've spent some time looking into the innards of Nominatim and reducing its storage requirements and cache footprint by choosing smaller types and playing \"column Tetris\". These changes had a nice effect on freshly loaded, indexed, and VACUUM FULLed extracts of Germany, Switzerland, and Italy:\r\n\r\ntable | original | tetris | tetris + hstore-address\r\n----- | -------- | ----- | ----------------------\r\nplace | 8522 MB | 8310 MB | 9367 MB\r\nplacex | 16693 MB | 15519 MB | 16757 MB\r\n\r\nBut, as you can see the space wasted by using `hstore` for address outweighs my savings.\r\nAn `hstore` uses 1 + 4 + 2×N×4 + size(keys) + size(values) (+3 (if more than 63)) bytes to store N key/value pairs. This sums up to 23 wasted bytes for each housenumber alone. Whereas adding an additional column just takes one bit (in the null-map) + size(value) if not NULL (when properly aligned)."}],"action":{"name":"View Pull Request","url":"https://github.com/openstreetmap/osm2pgsql/pull/737#issuecomment-294485823"}}}</script>