Dracodoc, Nice writeup. I'll respond on your stack exchange question.
That might be a good enhancement option to focus on for PostGIS 2.3. Haven't thought of how that filtering would work. Perhaps another geocode function that takes in a filter of desired states. Anyrate yah the geometry filter is not really optimized and was more designed for random polygon areas where you absolutely know an address has to fall, and it probably needs some performance work since I didn't spend too much time creating it. Thanks, Regina http://postgis.net http://www.postgis.us --- ORIGINA MESSAGE -- Hi all, I asked this question in gis stackexchange here already <http://gis.stackexchange.com/questions/171817/can-we-limit-the-search-range -of-geocode-function-in-postgis-tiger-geocoder>. I'm also posting the question in the mailing list to make sure the experts can see the question. I found the server with only 2 states data loaded is much faster than the server with all states loaded. My theory is bad formatted address that don't have a exact hit at first will cost much more time when the geocoder checked all states. With only 2 states this search is limited and stopped much early. There is a restrict_region parameter in geocode function looks promising if it can limit the search range, since I have enough information or reason to believe the state information in my addresses input are correct. I wrote a query trying to use one state's geometry as the limiting parameter: SELECT geocode('501 Fairmount DR , Annapolis, MD 20137', 1, the_geom) FROM tiger.state WHERE statefp = '24'; and compared the performance with the simple version SELECT geocode('501 Fairmount DR , Annapolis, MD 20137',1); I didn't find performance gain with the parameter. Instead it lost the performance gain from caching, which usually came from running same query immediately again because all the needed data have been cached in RAM. Maybe my usage is not proper, or this parameter is not intended to work as I expected. However if the search range can be limited, the performance gain could be substantial, since it's the bad formatted addresses took the most time to geocode, and they also often mess up the already cached data because the geocoder need to search for states, even all my input are in one state and all data can be cached in RAM. Thanks! By the way, I wrote about my system setup <http://dracodoc.github.io/2015/11/17/Geocoding/> and work flow <http://dracodoc.github.io/2015/11/19/Script-workflow/> in my blog. Wish it can help other novices in geocoding. _______________________________________________ postgis-users mailing list postgis-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/postgis-users