How accurate is the fast feature count supposed to be? An estimate could be pulled from the system stats pretty much instantly, but it wouldn't be exact.
I come to this question via the FDW work, where the first step PgSQL does is to try and plan the query and get selectivity estimates from all the nodes, including the FDW node. That means the FDW node is expected to return a guess of how many records the query will return, so I end up calling the OGR feature count method. But if it's really slow (as SELECT Count(*) can be) then thing will fall apart pretty quick. P. On Fri, Jan 16, 2015 at 12:39 PM, Even Rouault <[email protected]> wrote: > Selon Paul Ramsey <[email protected]>: > >> The PgSQL driver is returning TRUE for OLCFastFeatureCount and then running >> "SELECT Count(*)â to fulfill the request. Since that is actually going to >> apply a full table scan, itâ s not *really* a fast feature count in my >> estimation, but perhaps GDAL has a different standard? Whatâ s the standard >> for a fast feature count? Basically instant (the record count resides in >> header metadata or something similar)? Or â fast enough for small thingsâ ? > > Paul, > > The standard for "fast" is not well defined I think. Instant would be ideal, > but > a number of drivers advertize FastFeatureCount when they have a specialized > implementation that is faster than the generic one. In that instance the > request > is run entirely on server side, so this is much faster than the default > implementation. It is a bit surprising that PostgreSQL cannot maintain the > feature count without going to a full table scan, but I guess there are > technical difficulties related to concurrent updates to do so. > > Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
