[gdal-dev] Questions about SQL cursors in GDAL driver

[Jorge Arévalo]

2009/7/11 Tamas Szekeres <szekerest at gmail.com>:
> 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