Selon Martin Landa <landa.mar...@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@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
