On Thu, Aug 29, 2013 at 3:02 PM, Burgholzer, Robert (DEQ) < [email protected]> wrote:
> I just noticed something interesting, perhaps its trivial and well > understood, but this is the first time I figured it out (older postgis and > postgresql to boot). I am doing a spatial containment query on two tables, > table "a" being a point table in SRID 4326, with GIST index, and table "b" > being a polygon with GIST index in SRID 26918, using the "transform" > function to bring them into a common projection. If I apply the transform > to the polygon layer, the query planner (and indeed the query) is verrrry > slow, whereas, if I apply the transform to the point layer, things go along > much more swiftly. Now I know, so I just thought I'd share, if anyone has > any suggestions of course, I would be delighted to hear them. > Are you sure it's not the filter Filter: ((riverseg)::text = 'PS3_5100_5080'::text) that appears to only be present in the first query? I do notice that the estimate from the sc_cbp53 goes down from 1447 to 1 with the filter. EXPLAIN ANALYZE would give more information about what actually happened, and I wouldn't expect the query planner to behave the same in other versions of PostGIS. You might also benefit from a spatial index, and I believe in the older version, you need to do a bounding box check (&&) manually to trigger use of the index. (I can't recall which version, but one version of PostGIS built the && check into ST_Contains and many other functions.)
_______________________________________________ postgis-users mailing list [email protected] http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
