Hmm, I've given all of this a bit more thought.  Perhaps there is a need for a "simple" schema that is easy for people to populate and utilise.  I'm quite happy with hstore, but it's not as simple for those familiar with basic SQL.<br>
<br>The original reason I created the so-called simple schema was to support improved bounding box functionality because I couldn't do it via flat files efficiently.  It was called "simple" because I was also working on a full history schema that I never found time to complete.  My intent has always been to optimise for accurate bounding box query performance and not simplicity so the name is something of a misnomer.<br>
<br>Anyway, perhaps I should re-instate the old tasks and run them alongside the new ones.  I'll have to re-think the naming of these tasks and schemas.  Perhaps "simple" and "snapshot" or something ...<br>
<br>But I don't know when I'll get to do this.  I'm very time poor at the moment.<br><br><div class="gmail_quote">On Sat, Nov 20, 2010 at 11:47 AM, Brett Henderson <span dir="ltr"><<a href="mailto:brett@bretth.com">brett@bretth.com</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;"><div class="gmail_quote"><div class="im"><br></div><div><br>
Please keep in mind that the one and only reason I've switched to hstore is performance.  It has nothing to do with any perceived improvements in schema design or adherence to an alternative data storage philosophy.  It most certainly wasn't done for fun ;-)  I only switched after spending many days trying alternate ways of indexing the database, waiting (in some cases for several days) for full index builds to occur, and re-running benchmarks to measure improvements.  It was an incredibly tedious and frustrating experience that I only continued with in order to make the database scale more effectively to planet sized datasets.<br>

</div></div><br>Brett<br><br>
</blockquote></div><br>