[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):

 Okay that possibly explains why it eventually crashes when I wrapped it in
 my plpgsql function under VC++ build but seems to work fine outside of the
 function.

 As I recall I don't think the last one did though (I also had to change my
 code because I was getting a weird error when I wrapped it in the plpgsql
 function something like function did not return suitable structure.

 Well the ultimate solution would be to not have it set returning at all
 and just maintain the state of the rules/gaz/lex by matching if the SQL
 statements of those are the same -- which gets back to Paul's proposal of
 "do it like I do ST_Intersects"

 So in that model your prepared geom (or rather constant object would be
 the rules/gaz/lex)


 Whatever call would check to see if the sqls of these match and use the
 same if it does otherwise builds a new set and throws away the old. (Boy
 do I wihsi I understood Paul's code :).  That would make your code much
 more flexible too since one would not have to pass in an SQL statement and
 therefore could possibly skip a join and I wouldn't have to create a
 special batch version :) .

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/2260#comment:23>
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.