Optimize select #234
Description
I was equipped by the test case from #220 and saw significant difference between pure vshard call and crud's select even after PR #222 and PR #226. It was around 2 times, but I have no precise numbers under hands now. The bottleneck is on router.
Brief jit.p profiling does not show low hanging fruits anymore. Selective enabling / disabling of crud's code shows that, say, considerable amount of time is spent on creating select plan. Surprisingly, pcall() also leads to a visible slowdown. Checks was in the jit.p profile (around 5%, but it is by the profile, not by RPS).
Anyway, my observations were quite brief: let's look into this more systematically. Carefully review involved code and evaluate time spent in different parts of the code. Next, look what we can do to speed up our case.
The goal is to shrink crud / vshard RPS ratio to ~1.5.
Let's start from #225. (Update: it was implemented in PR #251.)
Observation: crud calculates a sharding key even when bucket_id is known (see plan.new()).(Update: this particular problem was resolved in PR #252.)
After we'll done here, we can look next on optimization of automatic sharding key determination case and look, whether there is a difference with user provided bucket id case (that's not in the scope of this issue).