[postgis-tickets] [PostGIS] #2260: Benchmarking speed between built-in tiger normalizer and pagc_address_parser

[PostGIS]

#2260: Benchmarking speed between built-in tiger normalizer and
pagc_address_parser
---------------------------------+------------------------------------------
 Reporter:  robe                 |       Owner:  robe         
     Type:  task                 |      Status:  new          
 Priority:  medium               |   Milestone:  PostGIS 2.1.0
Component:  pagc_address_parser  |     Version:  trunk        
 Keywords:                       |  
---------------------------------+------------------------------------------

Comment(by robe):

 Fairer test using pagc batch mode instead of individual call, but I think
 I have a memory leak somewhere.  Note prevent crashing on windows I had to
 remark out the SPI_finish call you have as mentioned in email
 conversations.

 This query takes 47ms - 78ms on my windows 7 64-bit mingw64
 {{{
 SELECT *
 FROM standardize_address('select * from lex', 'select * from gaz', 'select
 * from rules'
         , 'SELECT addid As id, (p).address1 As micro, (p).city || '', ''
 || (p).state || '' '' || coalesce('' '' || (p).zip,'''') As macro
 FROM (SELECT addid, parse_address(address) As p
 FROM test_parse WHERE addid NOT IN(3) ) As t ');

 }}}

 output:

 {{{
 WARNING:  transaction left non-empty SPI stack
 HINT:  Check for missing "SPI_finish" calls.
 id|building|house_num|predir|qual|pretype|name|suftype|sufdir|ruralroute|extra|city|state|country|postcode|box|unit
 1||529||||MAIN|STREET||||BOSTON|MASSACHUSETTS||02129||
 2||77||||MASSACHUSETTS|AVENUE||||CAMBRIDGE|MASSACHUSETTS||02139||
 4||26||||CAPEN|STREET||||MEDFORD|MASSACHUSETTS||||
 5||124||||MOUNT AUBURN|STREET||||CAMBRIDGE|MASSACHUSETTS||02138||
 6||950||||MAIN|STREET||||WORCESTER|MASSACHUSETTS||01610||
 7||949|NORTH|||3|STREET||||NEW HYDE PARK|NEW YORK||11040||
 8||35 W||||SERVICE|DRIVE|NORTHEAST|||BLAINE|MINNESOTA||55449||# 8401 W
 (7 rows)
 }}}

 I'm not sure if it helps but Jorge evidentally ran into this issue too
 when working with raster: http://www.postgresql.org/message-
 id/BANLkTi=B_y0TGh86T+Oy3XNpFqnDK006+w at mail.gmail.com

 His solution seemed to be use SPI_palloc instead of palloc.
 http://www.postgresql.org/message-
 id/BANLkTi=B_y0TGh86T+Oy3XNpFqnDK006+w at mail.gmail.com

 http://www.postgresql.org/docs/9.2/static/spi-spi-palloc.html

 I tried replacing some but didn't seem to help.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/2260#comment:5>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.