vtgate sql: enforce a max row count limit #4930
Conversation
I've been claiming that vtgate had a max row count limit. It turns out that I never actually implemented it. So, here's the implementation. Signed-off-by: Sugu Sougoumarane <ssougou@gmail.com>
There was a problem hiding this comment.
For backwards compatibility with production deployments this needs to have a much higher default, ideally infinite but at least 1 million.
As is this would break some slack workloads if deployed into production like this. Of course we can be diligent and override this default as part of the deployment, but as a general rule changes like this one that might affect some production deployments should really be disabled by default.
|
This was loosely based the fact hat vttablets already limit the max count to 10K. Are there workloads that pull under 10K from each vttablet, that still add up to over 30K? |
Definitely. We have some scatter queries that absolutely hit that. I just checked. :) |
|
Can you check if they were using OLTP, and not OLAP? Note that it's a bad idea to do it this way. We've always said that one should use OLAP if fetching more than 10K rows. The main motivation behind this limit is to prevent site-wide outage from a rogue query. If it pulls too many rows, it can OOM all the vtgates. Ideally, we should have a global limit. But that's hard to track and enforce. So, this is some kind of a start. Will 100K be reasonable? |
|
Slack doesn't use OLAP anywhere. Yes we realize there are probably better ways to do this... but in the global scheme of tradeoffs what we have is the least-bad. |
I've been claiming that vtgate had a max row count limit.
It turns out that I never actually implemented it.
So, here's the implementation.
Signed-off-by: Sugu Sougoumarane ssougou@gmail.com