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.
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. 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 ... But I don't know when I'll get to do this. I'm very time poor at the moment. On Sat, Nov 20, 2010 at 11:47 AM, Brett Henderson <br...@bretth.com> wrote: > > > 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. > > Brett > >
_______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
