Vitali Diatchkov ha scritto: > > Just a hint from my mind related to our projects. > > There are situations when 20 layers from Oracle are being rendered. The data > is spread among the whole territory of Finland and the often situation is > when there is no data to be rendered at the specified scale ratio for 17 of > 20 layers. But every renderer not only requests features but also calls > getCount() method to perform real checking to be sure that there is no data > to be rendered if empty feature collection has come in the beginning. > getCount() leads to "SELECT count(*) FROM.. WHERE.." and so on in case of > OracleDataStore - for these 17 layers from 20. Totally we have 3 + (17 * 2) > requests to the database (if we have 20 layers and only 3 of them contain > features inside of current Filter).
Eeek, getCount() on a big table can take tens of seconds (if you have millions of records). > Did not investigate deeply but there > should be a preference to switch off this getCount() call from renderer in > case no features were loaded during usual request. > Isn't it the GT renderer calls this stuff, not UDIG wrappers ?... do not > remember exactly, but anyway - it would be good optimization to switch off > this call. I could not find any getCount call in StreamingRenderer. Then I put a breakpoint in JDBCFEatureSource.count(xxx,xxx) and issued a GetMap request in GeoServer and the breakpoint was never reached, so I believe there is nothing in StreamingRenderer asking for row count (all counting code I know of in the end delegates to FeatoureSource.getCount(xxx)). I would suggest you do the same with uDig and your datastore and see what code triggers this call. I'm curious, me too. Cheers Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
