[gdal-dev] ogr-pg: GetFeature() speed

[Even Rouault]

Selon Martin Landa <landa.martin at gmail.com>:

I'm not shoked at all by the performance you see. I would have even expected it
to be worse. Fetching 10 000 features in 5.6s, means 0.56 millisecond per
feature. Not so bad. You have to pay the cost for a client/server dialog for
each GetFeature() call whereas GetNextFeature() fetches 500 features at a time.

Looking at OGRPGTableLayer::GetFeature() implementation, I see we use a cursor
to wrap the SELECT. I'm not sure why this is necessary when the result should be
just one feature. You could experiment and try removing it, but I'm not sure it
would really improve the performance.

Another idea would be to issue one query for several features, if you can afford
doing grouped queries. You would do a ExecuteSQL("SELECT * FROM your_layer WHERE
ogc_fid IN (fid1, fid2, ... fidn)"

> Hi,
>
> I have tested speed of random access to PostGIS features with simple
> testing application.
>
>     // about 1e4 points
>     poLayer = poDS->GetLayerByName("bridges");
>
>     nfeatures = poLayer->GetFeatureCount();
>
>     for (int fid = 1; fid < nfeatures; fid++)
> 	poFeature = poLayer->GetFeature(fid);
>
> and sequential access
>
>     while(1) {
> 	poFeature = poLayer->GetNextFeature();
> 	if (!poFeature)
> 	    break;
>     }
>
> I would expect that random access will be slower, anyway not so much.
>
> random access
>
> real    0m5.612s
> user    0m1.432s
> sys     0m0.512s
>
> sequential access
>
> real    0m0.248s
> user    0m0.116s
> sys     0m0.012s
>
> Are there any possibilities how to speed up random access (not
> speaking about sample application where should be used seq access).
>
> Thanks in advance, Martin
>
> --
> Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>