>>12216036No, it's not. Your error lies in the missing set segmentation. In your model, you cannot reduce the whole set to a subset of candidates, because in order to check whether an element is part of the desired subset, you have to actually perform a modulo check on every single row of your database. So, for checking e.g. a database of citizens for a specific ZIP code "group product", you must calculate the modulo of pretty large primes on every single database row. In case of a bucket/hash-based index, you can immediately reduce the full set of all database rows to only those who share the same ZIP hashcode, which you can then easily check to really equal the desired ZIP code. In terms of numbers: if theres a database with 100 million rows of citizens, your prime approach requires to calculate the modulo of 100 million rows "ZIP code prime products" in order to e.g. identify 50000 citizens with that ZIP code. A bucket/hash-based approach would have immediately reduced the 100 million rows to e.g. 59000 rows who are known to have exactly the desired hash, and you'd have to only check those 59000 for their ZIP code really being the desired one, because there might have been other ZIP codes ending up in the same bucket/hashcode... what do you think is faster - doing the modulo on 100 million big numbers, or 59000 "do the ZIP codes match" comparisons?
