Now, this will give the possibility of false matches, depending on how you index. For example, the phrase "in the" might end up matching "Come on in. The tea is on the stove."

Another problem is 3+ word phrases. The system I'm proposing will tell you if pairs are in the right order. But, using the above snippet, "in the stove" would match that document because "in the" and "the stove" are both phrases that exist, even though "in the stove" isn't there.

But, it all depends on how perfect you want to be. "Good enough, I can give you now. Perfect will be along tomorrow."

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Phrase matching is not the same as "and" matching.

Agreed. Sorry if implied otherwise. But once you have a list of the records that contain all the terms, then validating these against the original phrase is considerably less costly than searching the whole 20MB.

Good point. Using index on the keys of the hash does make more sense.

Makeshifts last the longest.