[postgis-users] Geocoding on Windows very slow
Paragon Corporation
lr at pcorp.us
Thu Sep 26 20:58:40 PDT 2013
Jonathan,
IT's hard to say since like I said unfortunately you have a bad build. You
should probably upgrade your scripts to 2.1.1 version (which is now upgraded
to use new tiger 2013 data). I made a lot of corrections since the build you
have. One major one that comes to mind is that in PostgreSQL 9.2 I noticed
it was slower for some things than it was in 9.1.
So to work around the problem I had this line which is in the newer
versions. You might want to check that is set on your function or play
around with it.
ALTER FUNCTION tiger.geocode_address(norm_addy, integer, geometry) SET
join_collapse_limit='2';
To debug the plans, we have some settings stored in geocode_settings table
http://postgis.net/docs/manual-2.1/Set_Geocode_Setting.html
Try SELECT set_geocode_setting('debug_geocode_address', 'true') As result;
This will output the generated SQL in NOTICE. You can then run the code
threw EXPLAIN to see where the time is being spent.
Hope that helps,
Regina
http://www.postgis.us
http://postgis.net
-----Original Message-----
From: postgis-users-bounces at lists.osgeo.org
[mailto:postgis-users-bounces at lists.osgeo.org] On Behalf Of Jonathan Haglund
Sent: Thursday, September 26, 2013 3:30 PM
To: PostGIS Users Discussion
Subject: [postgis-users] Geocoding on Windows very slow
The following query takes around 28 seconds to complete:
select g.rating, ST_X(geomout) as lon, ST_Y(geomout) as lat, (addy).* from
geocode( '601 15th Ave NW, Birmingham, Alabama, 35215', 1 ) as g
I did select install_missing_indexes(), tried vacuum analyze on the
top-level tables, and thrown lots of resources and posgresql. My system
does not want for CPU or ram, the databases are on a raid 10. I have 17
states' data loaded, in case that matters.
When I loaded the tiger data I ran into a problem with the windows version
of the scripts and had to alter the top-level tables before being able to do
the states. As a result tlid moved to the last position. I made no other
alterations. I think this would affect index performance on mysql but I
don't have experience with this in postgresql, so that's part of my
question.
What might I look for next in troubleshooting? Does 2.1 promise to fix all
my woes as I have read in other performance questions?
My versions:
PostgreSQL 9.2.4, compiled by Visual C++ build 1600, 64-bit
POSTGIS="2.0.3 r11132" GEOS="3.3.8-CAPI-1.7.8" PROJ="Rel. 4.8.0, 6 March
2012" GDAL="GDAL 1.9.2, released 2012/10/08" LIBXML="2.7.8"
LIBJSON="UNKNOWN" RASTER
_______________________________________________
postgis-users mailing list
postgis-users at lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
More information about the postgis-users
mailing list