--- P Kishor <[EMAIL PROTECTED]> wrote: > On 8/26/06, Joe Wilson <[EMAIL PROTECTED]> wrote: > > The sample poly.name's you've provided in your example seem to be integers. > > Is that always the case? Are the poly_id's unique? If both of these > > are true, you might consider making poly_id your primary key in the > > polys table in order to eliminate a column. > > Poly_ids are indeed integers and unique, and they are also a primary > key. Although, I don't understand how that allows me to eliminate a > column.
I meant to say are the poly.name's unique integers? If so, then poly.name can be the integer primary key instead of poly.poly_id. > > This problem is very difficult to do in pure SQL efficiently. > > Actually, I have tried many other approaches, and SQL seems to be a > fairly efficient one. Here is why -- in the worst case, I have to test > each point against each poly (a geometry algorithm allows me to test > if the point is definitely in the poly or not). That is the worst > case, as it is 200k X 5 mill = 1 trillion transactions. You don't have to test each point against each poly if wisely use the 4 in-memory sorted perl poly ref arrays. 5m points x log2(200k polys) x 4 = 352m in-memory comparisons maximum. You could process the 5 million points in less than an hour in perl, or in just a few minutes in C/C++ or Java. Of course this is just computation/matching time. It excludes the additional time it would take to update the names of the points in the database. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
