[gdal-dev] OGR SQL performance issue with VRT as a source?

[Rahkonen Jukka]

Hi,

It seems to me that sorting is the slow part. If you just need to get the job done, try
ogr2ogr -sql "SELECT CAST(MAX * -1 AS INTEGER) AS depth FROM merged" sample_vrt-ogr.geojsons sample.vrt

-Jukka Rahkonen-


________________________________________
Lähettäjä: gdal-dev <gdal-dev-bounces at lists.osgeo.org> käyttäjän Andrey VI via gdal-dev <gdal-dev at lists.osgeo.org> puolesta
Lähetetty: Maanantai 20. lokakuuta 2025 11.47
Vastaanottaja: gdal-dev at lists.osgeo.org <gdal-dev at lists.osgeo.org>
Aihe: [gdal-dev] OGR SQL performance issue with VRT as a source?

Hi all.I have found a significant performance drop when using OGR SQL with VRT as a source. Test results with sample data (link, 6,8 MB).VRT as a source: $ time ogr2ogr -dialect sqlite -sql "SELECT geometry, CAST(ABS(MAX) AS INT) AS depth FROM merged ORDER BY MAX DESC" sample_vrt-sqlite.geojsons sample.vrtreal    0m3,960suser    0m0,037ssys     0m0,022s$ time ogr2ogr -sql "SELECT CAST(MAX * -1 AS INTEGER) AS depth FROM merged ORDER BY MAX DESC" sample_vrt-ogr.geojsons sample.vrtreal    3m4,108suser    0m0,057ssys     0m0,016s Shapefile as a source:$ time ogr2ogr -dialect sqlite -sql "SELECT geometry, CAST(ABS(MAX) AS INT) AS depth FROM sample ORDER BY MAX DESC" sample_shp-sqlite.geojsons sample.shpreal    0m3,627suser    0m0,036ssys     0m0,025s$ time ogr2ogr -sql "SELECT CAST(MAX * -1 AS INTEGER) AS depth FROM sample ORDER BY MAX DESC" sample_shp-ogr.geojsons sample.shpreal    0m3,731suser    0m0,052ssys     0m0,025s Since my VRTs consist of tens and hundreds of Shapefiles, OGR SQL becomes unusable for the specific task given as an example above.So I wonder what could be the reason for such a significant drop in performance in this particular case? Or maybe I’m doing something wrong?--Andrey