I've been wondering if hstore would be a good addition to the Osmosis "simple" schema which does store junction information.  I wonder if a combination of tags stored in a hstore column, and table data clustered by GIST indexes on node.geom and way.linestring columns (ie. to organise the data geographically) has the potential to reduce the amount of disk seeks required for queries returning large numbers of rows.<br>
<br><div class="gmail_quote">On Thu, Jul 8, 2010 at 8:55 PM, Peter Körner <span dir="ltr"><<a href="mailto:osm-lists@mazdermind.de">osm-lists@mazdermind.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
<br>
Am 08.07.2010 11:46, schrieb John Smith:<div class="im"><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Does anyone know if pgsql hstore would facilitate something like XAPI<br>
with similar performance, but allow multiple parameters?<br>
</blockquote>
<br></div>
The performance will be highly dependent on the number of queries but I think it will be in a similar range. One ting to remeber is, that osm2pgsql does *not* store junction information, just simple geometries. This makes it suitable for most display purposes but eg. not usable for routing. That's also the reason why you can't generate .osm format from osm2pgsql databases without the (possible slow) access to the _node, _way or _relation tables.<font color="#888888"></font><br>
</blockquote></div><br>