Open derekperkins opened 1 year ago
Hi @derekperkins!
- There are docs for format=vtexplain (link), but not format=vitess
In V16, we are replacing format=vitess
with vexplain
. That is better documented: https://vitess.io/docs/16.0/user-guides/sql/vexplain/
Unfortunately, we are not likely to prioritize updating docs on a deprecated command on the V15 docs.
If there is anything in particular you are curious about, feel free to ping me on Slack
in an older version of Vitess (v5 era), we avoided a scatter query when using a multi-column IN clause by extracting out the sharding key into a separate single IN. e.g.
Revisiting this in v15.0.2, support has improved somewhat, but still has room for improvement. The route operator is
MultiEqual
instead ofIN
, which isn't clear from the docs whether it is better/same/worse than theIN
variant (see https://github.com/vitessio/vitess/pull/7049) . Digging in a little deeper, we can see that the single columnIN
is correctly pruned per partition, while the multi-columnIN
just sends the entire query to each shard.We often have queries with hundreds of multi-column
IN
values, and where vtgate is already correctly pruning single column values, it would be more performant to also prune multiple column values. This was particularly bad a while ago when we were testing out MyRocks, which IIRC is particularly slow on non-existent key lookup.Some form of this exists already for DML, since multi-value inserts are pruned per shard, but it seems likely that is handled in a different section of the codebase.
with single column IN
without single column IN
Related:
Side notes:
format=vtexplain
(link), but notformat=vitess
cc @vitessio/query-serving