Opened 21 years ago
Closed 14 years ago
#460 closed defect (wontfix)
Query Efficiency
Reported by: | Owned by: | sdlime | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | MapServer CGI | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: | bartvde@… |
Description (last modified by )
1. Noone seems to know how the query (itemquery, itemnquery) mechanics actually work. Some investigation and documentation are needed. 2. The query method appears to be (a) do a query-by-rectangle (with filter) to get record#s, then (b) repeatedly request each feature by record number. In order for this to be efficient, it assumes a O(1) get-feature-by-record-number access. This isnt true for all layer types. Also, cacheing the results of the query-by-rectangle (with filter) isnt generally possible because the columns (items) havent been set yet in the layer object or by a call to LayerGetItems(). 3. Why is there a separate query/draw mechanism? Why doesnt mapserv just do a normal draw-type request (query-by-rectangle (with filter)), then use the normal getNextShape() functions? Its a maintainance issue to have each layer implement two basic functions (draw and query) when query could be seamlessly implemented by the draw mechanism. C.F. mailing list discussion with subject "Re: [Mapserver-dev] Re: [Mapserver-users] Mapscript drawQuery() on big PostGIS layers doesn't work properly ?" Daniel requested a bug report so this doesnt go away.
Change History (5)
comment:2 by , 21 years ago
Owner: | changed from | to
---|
1. I know how they work. What do you want know? 2. Which layer types don't support feature access by number? The only one can recall is Oracle Spatial but it's not clear. Mind you this is how drawing works too. Where queries differ is that they store IDs for processing later through the templates. This requires accessing them twice which is definitely inefficient but queries generally don't have to be as snappy. Part of the reason only IDs are cached is that large queries could eat up tons of memory. We could cache entire shapes and attributes as long as care is taken with large result sets. This makes saved queries very difficult, but actually outputing shapes as GML might be a possibility. 3. Cause it was a kludge and should be re-written. Queries can be much more complex then rect/filter searches (e.g. feature queries) so they have to work off a cache of some sort.
comment:3 by , 21 years ago
Cc: | added |
---|---|
Status: | new → assigned |
For SDE and shapefiles feature ID based access is quite fast (those were my models when writing that code). If that's not the case in general then I need to fix the issue. Caching entire shapes with attributes would be the answer. This would not be hard and would generally simplify life but would touch a lot of code so it would be time consuming. Steve
comment:4 by , 20 years ago
Cc: | added |
---|
comment:5 by , 14 years ago
Description: | modified (diff) |
---|---|
Resolution: | → wontfix |
Status: | assigned → closed |
Um, closing as WONTFIX... Always improving functionality.
Note:
See TracTickets
for help on using tickets.