[Mapserver-dev] Query efficiency
steve.lime at dnr.state.mn.us
Wed Mar 3 13:23:25 EST 2004
I don't know what various databases do with caching. There is no notion
of a result set (other than a list of indicies) within MapServer, and
certainly nothing source specific. That's probably a good place to look
starters. I could see allowing each supported datasource type
it's own version of a result set (e.g. a list of indicies for
shapefiles) and then
we write generic wrappers to access the result set. That way a
datasource would not be forced down the "get shape by id" path that
well for shapefiles. The Refractions folks would be in the best
comment since they know PostGIS far better than anyone knows SDE or
Oracle Spatial. This probably complicates the notion of cached
>>> <bartvde at xs4all.nl> 3/3/2004 7:37:56 AM >>>
would it not make sense to make a difference between local
like shapefiles, and (spatial) database datasources?
When you have a database datasource you can leave a lot of work to the
database, including the caching of query results.
It doesn't seem logical to me that 2 queries are needed in the current
design for all datasources (for a database datasource 1 query should
suffice most of the times).
But I don't know if this fits into the current design of Mapserver
So perhaps not the caching of result sets is the solution (although
a nice enhancement feature I guess), but changing the way the queries
sent to the database datasources is the way to go.
Just a thought.
> Hi guys: The issue of query efficiency keeps coming up these days as
> queries are not simply a means to an end. SVG, image maps etc... are
> going to push the current code, especially with non-shapefile
> datasources. I/we need to figure out a way to cache shapes that are
> of a query result set. We could use the inline feature structures to
> this but I worry about huge result sets, and/or could consider
> serializing shapes to some high performance format. There are some
> interesting possibilities with the latter. Query caching could be
> very efficient (e.g. queryfile/savequery CGI options) and that
> could be useful for regular layers too, kind of like the gd2 format.
> What do folks think?
> Mapserver-dev mailing list
> Mapserver-dev at lists.gis.umn.edu
Mapserver-dev mailing list
Mapserver-dev at lists.gis.umn.edu
More information about the mapserver-dev