"Jose" <jmalv04@gmail.com> wrote
Below are my results with g++ -O3
The query should group by city given that in the aslatlong.txt file all AS in a city have the same (lat, long). This would make the output more useful (right now the query outputs all the AS from amsterdam first which is redundant info given that all AS in the amsterdam area have the same lat/long)
================================================== loading table... 21598 records loaded 3317 AMSTERDAM ? 991 [ ... ] The query took 11 sec 0 records will be added to the index 1982 records will be removed from the index done with updates 5390 AMSTERDAM ? 990 [ ... ] Update and query re-run took 0 sec ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Would it be possible for you to change the code a little, so that it outputs milliseconds here?
Right, so I am afraid we may fall into the trap of comparing the cleverness of hand-coded solutions rather than the libraries' capabilities.
I don't think this is exactly right. Geographic queries should have some additional logic that may well be part of the library.
I would rather it belong to a separate library, highly compatible with the relational one.
I don't think either library has this type of logic now so both might have a hand coded solution for the time being
Right, but the relative impact of these hand-coded solutions maybe too high, so we may not really be comparing the libraries. At this point the RTL solution is coded completely as a relational expression (although rather complex), a single relational view. I also might be able to further optimize it inside the relational boundaries. Please note also that I had to somewhat decrease the performance in exchange to fast re-runs after the update, so, depending on the context (update and re-run pattern, etc.), RTL solution might even now be much more efficient than it looks. Regards, Arkadiy