[Tile-serving] Hstore benchmarking results

[Paul Norman]

Heading out, so this message is brief

> From: Frank Broniewski [mailto:brfr at metrico.lu]
> Sent: Wednesday, March 05, 2014 11:39 PM
> Subject: Re: [Tile-serving] Hstore benchmarking results
> 
> Am 2014-03-06 06:52, schrieb Paul Norman:
> > I've released some results of benchmarking of performance with
> > hstore on my blog at
> > http://www.paulnorman.ca/blog/2014/03/osm2pgsql-and-hstore/
> >
> > The short version of the results is
> >
> > - Use -k (--hstore), don't use --match-only or -j (--hstore-all)
> >
> > - There is very little performance hit for -k
> >
> > - There is more of a size increase
> >
> >
> > _______________________________________________ Tile-serving
> > mailing list Tile-serving at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tile-serving
> >
> 
> Hi Paul,
> 
> I find your test quite interesting, as I am one of the persons who
> uses the --hstore-all option for my database. I find it quite
> convenient to have the attributes of an geographic object in one
> column. Mostly because I only need one index on the hstore column
> instead of putting an index on my most required columns.

Keep in mind that GIN indexes are very slow to build, and that to 
Properly use hstore you need to rewrite queries (i.e. WHERE NOT 
 tags?'foo' rather than WHERE tags->'foo' IS NULL)

Partial indexes are a bit more of a pain to define as well, and partial
indexes are important for getting performance.

None of this changes that --hstore-all probably isn't what you should be
using, it's --hstore with a slimmer .style.

> I was also already thinking of removing most columns from the style
> file and only leaving those which are always used and don't require an
> index, like name for example.

This is on my to-benchmark list, and I think the import finished overnight.