Re^2: same query, different execution, different performance

in reply to Re: same query, different execution, different performance
in thread same query, different execution, different performance

Thanks Marshall. Makes a lot of sense.

when small people start casting long shadows, it is time to go to bed

Comment on Re^2: same query, different execution, different performance

Replies are listed 'Best First'.
Re^3: same query, different execution, different performance by Marshall (Canon) on Feb 14, 2012 at 04:33 UTC
Another idea occurred to me - don't know if it would work or not - but an experiment should be easy for you... If you are always adding this % wildcard at the end, what happens if you put that wildcard into the version 2 prepare? i.e. LIKE ?% instead of LIKE ? In this case you would just put in the raw $q "abc" instead of "abc%". In my simple "untested code" brain, that might trigger the DB to use the index, knowing that it will start out the search with a constant term that you provide. I personally do not know the answer. But on the surface it sounds plausible. Anyway I think it would be fun the hear the results of that test. This is likely to be DB specific, but never-the-less interesting. I think the chance of success is low, but this critter may be smarter than we think. I am working on some complicated approximate matches in SQLite. This may not apply in your case, but consider that if case is not an issue: ABC% must all fall between x >="ABC" and x<"ABD" in a string comparison sense depending upon how the DB is indexed and other confounding factors...	[reply]

Replies are listed 'Best First'.

Re^3: same query, different execution, different performance
by Marshall (Canon) on Feb 14, 2012 at 04:33 UTC

If you are always adding this % wildcard at the end, what happens if you put that wildcard into the version 2 prepare? i.e. LIKE ?% instead of LIKE ? In this case you would just put in the raw $q "abc" instead of "abc%". In my simple "untested code" brain, that might trigger the DB to use the index, knowing that it will start out the search with a constant term that you provide.

I personally do not know the answer. But on the surface it sounds plausible. Anyway I think it would be fun the hear the results of that test. This is likely to be DB specific, but never-the-less interesting. I think the chance of success is low, but this critter may be smarter than we think.

I am working on some complicated approximate matches in SQLite. This may not apply in your case, but consider that if case is not an issue: ABC% must all fall between x >="ABC" and x<"ABD" in a string comparison sense depending upon how the DB is indexed and other confounding factors...

[reply]

In Section Seekers of Perl Wisdom