[Mapserver-dev] Query efficiency

[Sean Gillies]

OK, I guess my understanding of the query limitations hasn't been
so good.

Could the shape cache be something that might be generally useable?
Here's a use case I am thinking of:

Currently, if a mapscript application has a set of shapes the way to
map them is to iterate over the shapes and call shape.draw() for
each.  Brutally slow.

It seems like it would be great to be able to push these shapes into
the shape cache and use a draw method of the shape cache to more
efficiently draw shapes.

Is this use outside your scope?

Sean

On Mar 3, 2004, at 11:58 AM, Steve Lime wrote:

> 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
>>
>
> _______________________________________________
> Mapserver-dev mailing list
> Mapserver-dev at lists.gis.umn.edu
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
>