improvement: better disjoint where clause evaluation

[icehaunter]

Right now, when Electric knows about N shapes with where clauses, we're quite naive about figuring out which shapes does a given transaction fall into. For example, if we have N shapes over the same table with where clauses in the pattern of WHERE id = $1.

We can improve the performance and reduce the CPU usage if we're smarter about it. For the example above, we can infer that if one of the where clauses is true, all the others are false and we don't need to evaluate them. Moreover, for = check, we can precompute a lookup structure to know in one lookup which where clauses of the set can evaluate to true at all. If where clauses have WHERE ID = $1 AND .... form, then we can cut away definitely-false where clauses and execute only M << N checks instead.

The precomute can be done on a relatively rare event of shape creation (rare in relation to transaction processing).

[balegas]

I'm not fan of early optimizations, but I'm interested in knowing the speed up when we have lots of shapes in that format, which seems it's going to be a frequent pattern.