[Mapserver-dev] Query efficiency
Bart van den Eijnden
bartvde at xs4all.nl
Wed Mar 3 14:37:27 EST 2004
no you're absolutely right about the mixing.
The problem that was noted was a bad performance of Mapserver queries on
A possible solution to improve the performance would be #1 (caching
But I think the bad performance is also caused by the way Mapserver
queries work against databases (#2 in your list).
On Wed, 03 Mar 2004 14:11:03 -0500, Daniel Morissette
<dmorissette at dmsolutions.ca> wrote:
> Steve Lime wrote:
>> 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
>> 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
>> position to
>> comment since they know PostGIS far better than anyone knows SDE or
>> Oracle Spatial. This probably complicates the notion of cached
> What we mean exactly by "caching queries"? I see two possible meanings:
> 1- Caching results between multiple hits to the CGI (or to mapscript
> 2- Optimizing MapServer's internals to avoid doing multiple passes on
> the data in a single request when doing query-related operations.
> Is it just me, or are we mixing both here?
> I have a feeling that we're talking about #1, but some people are hoping
> that you're talking about #2.
More information about the mapserver-dev