[mapguide-trac] #1888: GwsQueryEngine evaluates incorrect join algorithm for joins involving SDF/SHP sources

[MapGuide Open Source]

#1888: GwsQueryEngine evaluates incorrect join algorithm for joins involving
SDF/SHP sources
----------------------+-----------------------------------------------------
   Reporter:  jng     |       Owner:     
       Type:  defect  |      Status:  new
   Priority:  high    |   Milestone:  2.4
  Component:  Server  |     Version:     
   Severity:  major   |    Keywords:     
External_id:          |  
----------------------+-----------------------------------------------------
 Sortability is a critical metric for optimum feature join performance.

 Currently the GwsQueryEngine does a check to see if select ordering is
 supported via the FDO provider capabilities. This check is not actually
 the final determinator for sortability, because sorting is also exposed
 via the FdoIExtendedSelect command, but this command only allows sorting
 on one property.

 Therefore SDF/SHP sources, though they do not support standard select
 ordering, do support ordering via the FdoIExtendedSelect command, so the
 GwsQueryEngine needs to check for this as well.

 Attached is a patch that updates the sortability check. A given side of
 the join supports ordering if <it supports standard select ordering>
 --OR-- <it supports FdoIExtendedSelect command and only one property is
 being joined>

 In my test cases, a full read from our joined test data (Sheboygan Parcels
 split into <ID/Geom> and <Attribute> halves, in SDF and SQLite flavours),
 where it previously used Nested Loops or Nested Loops sorted block
 (because the SDF side failed the sortability check, resulting in 20min
 execution time), it now uses sort merge (both sides pass the sortability
 check, resulting in 20s execution time).

-- 
Ticket URL: <http://trac.osgeo.org/mapguide/ticket/1888>
MapGuide Open Source <http://mapguide.osgeo.org/>
MapGuide Open Source Internals