You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This doesn't work in MySQL, so we need to remove it before we migrate.
We may want to replace it with random ID generation rather than auto-increment, if we're worried about the efficiency of inserting 100 rows for a maximally-sized newOrder request.
The text was updated successfully, but these errors were encountered:
Behind that flag, replace multi-inserter with a bunch of (parallel) single inserts
Use the SA's existing "parallelismPerRPC" config to control the parallelism here
We also probably want to reduce the configured parallelism per RPC, as we believe that may have been a contributing factor in the SA<->ProxySQL connection churn we've historically had problems with.
From there, we can flip the flag in staging/prod, and easily turn it off if it causes problems. If it doesn't cause problems, we're good here -- if it does cause problems, we can dive into batch inserts, random ID generation, and all the knock-on effects of that.
…thzs (#7739)
This is our only use of MariaDB's "INSERT ... RETURNING" syntax, which
does not exist in MySQL and Vitess. Add a feature flag which removes our
use of this feature, so that we can easily disable it and then re-enable
it if it turns out to be too much of a performance hit.
Also add a benchmark showing that the serial-insertion approach is
slower, but perhaps not debilitatingly so.
Part of #7718
This doesn't work in MySQL, so we need to remove it before we migrate.
We may want to replace it with random ID generation rather than auto-increment, if we're worried about the efficiency of inserting 100 rows for a maximally-sized newOrder request.
The text was updated successfully, but these errors were encountered: