[Mapserver-dev] Query efficiency

Steve Lime 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
there is
certainly nothing source specific. That's probably a good place to look
for
starters. I could see allowing each supported datasource type
maintaining
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
particular
datasource would not be forced down the "get shape by id" path that
works
well for shapefiles. The Refractions folks would be in the best
position to
comment since they know PostGIS far better than anyone knows SDE or
Oracle Spatial. This probably complicates the notion of cached
queries.

Steve

>>> <bartvde at xs4all.nl> 3/3/2004 7:37:56 AM >>>
Hi Steve,

would it not make sense to make a difference between local
datasources,
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
queries.

So perhaps not the caching of result sets is the solution (although
always
a nice enhancement feature I guess), but changing the way the queries
are
sent to the database datasources is the way to go.

Just a thought.

Best regards,
Bart

> 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
part
> of a query result set. We could use the inline feature structures to
do
> 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
made
> very efficient (e.g. queryfile/savequery CGI options) and that
format
> could be useful for regular layers too, kind of like the gd2 format.
>
> What do folks think?
>
> Steve
> _______________________________________________
> Mapserver-dev mailing list
> Mapserver-dev at lists.gis.umn.edu 
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev 
>

_______________________________________________
Mapserver-dev mailing list
Mapserver-dev at lists.gis.umn.edu 
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev



More information about the mapserver-dev mailing list