[Mapserver-dev] Query efficiency

Steve Lime steve.lime at dnr.state.mn.us
Wed Mar 3 13:58:09 EST 2004


Sean: Queries work by first generating a candidate result set and then
operating on that result set within MapServer (applying classes etc...).
Queries cannot be completely executed in the underlying RDBMS (as the
code sits). So there's this disjoint relationship between the result set
and the database. The fix would be to enable all queries in a vendor
specific way and then maintain access to the result set using the
msLayerNextShape() function. 

The current code gives us very consistent results between datasources
because the same algorithms (good or bad) are used for everything.
Unfortunately is doesn't let us tap into the power of the database
except for attribute queries.

Steve

>>> Sean Gillies <sgillies at frii.com> 3/3/2004 12:43:07 PM >>>
Steve,

My initial reaction was that a shape cache would be good.  Then I
read the other comments, and I tend to agree that people who want
better performance like they could get from a spatial RDBMS should
use a spatial RDBMS.

Just my $.02
Sean

On Mar 3, 2004, at 10:51 AM, Steve Lime wrote:

> Yes.
>
>>>> Sean Gillies <sgillies at frii.com> 3/2/2004 11:14:49 PM >>>
> By query caching do you mean the result of a query would be a set of
> shapes
> rather than a set of shapeindexes?
>
> Sean
>
> On Mar 2, 2004, at 9:09 PM, Steve Lime wrote:
>
>> 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