Josh Berkus wrote:
> MLW,
>
> > > The U.S. Census provides a database of street polygons and other
data
> > > about landmarks, elevation, etc. This was discussed in a separate
> thread.
> > >
> happy to see someone put together a "huge table" test using the Tiger
> database, but for general tests we're aiming more at the 50-100mb
size.
The Tiger US street level data would be an excellent test of the polygon
storage and extraction routines. My information might no longer be
current, but the last time I checked Tiger gave the street level data
out on cd (er, cds) as one huge table of disconnected road 'segments'
broken up by state. Connecting the segments into longer streets for
more meaningful processing is a good benchmarking procedure. I this is
interesting strictly on that level. It doesn't test the optimizer or
esoteric features much (except for geo features), but is a good test of
index/cache/random tuple access. It's typical of the scientific/data
processing problem domain that is much less common (but much more
interesting!) than your average business based app. I definitely
understand mlw's thinking.
That being said, since major competitors lack the robust geo
types/indices of postgres (the only way, IMHO, to do this type of
thing); it wouldn't be a very fair test. I would like to point out the
problem is scalable by picking one state e.g. Rhode Island :), and
building off that. One thing at a time tho.
It's no accident we have a 'PostGIS' and not a 'MyGIS' :)
Merlin