2009/7/11 Tamas Szekeres <[email protected]>: > Jorge, > > I think this driver is in a special situation comparing to the file based > raster data sources, that is: we should minimize the round trips to the > server as much as possible which is costly. Therefore in addition to write > IReadBlock correctly (required to fetch a single row in each call or > multiple rows with the non-regular blocking option) we should also consider > to implement some further optimizations. > > In the current case GDALRasterBand::IRasterIO would trigger a number of > IReadBlocks to the driver which will cause many individual round-trips to > the server which is a 'sub-optimal' solution in our case. > > In this driver - I think - we should actually override > GDALRasterBand::IRasterIO and try to fetch all the blocks by using a spatial > query according to the area requested by the user. Then the driver should > feed the returned blocks into the band block cache by creating a new > GDALRasterBlock for each returned row, and call GDALRasterBand::AdoptBlock > to add the block to the cache. (see GDALRasterBand::GetLockedBlockRef for > more details how the block handling is done in general). Then you could call > the IRasterIO on the base class to do the rest of the IO operation. > By feeding up the cache with the blocks the base RasterIO will be served > from the block cache instead of calling the IReadBlock-s individually. > > But this option doesn't invalidate the requirement of implementing > IReadBlock which is compulsory for each driver to provide the block based > access. > Added to TODO list. I think a deeper investigation on the internals of how and when are the methods of RasterBand called could help me a lot. Maybe I should review the code of gdalinfo, or other GDAL apps. Any suggestion?
> > With regards to the cursors it should also be avoided here, because (in > addition to the roundtrips) it requires further resource allocations at the > server which decreases the scalability and by using random access to the > rows may not perform better than accessing the data by using a (clustered) > index search for example. Ok. No cursors. Index based search. That's my point just now. Many thanks Best regards Jorge _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
