Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sql: the Insert planNode runs everything in one humongous batch #16180

Closed
andreimatei opened this issue May 26, 2017 · 2 comments
Closed

sql: the Insert planNode runs everything in one humongous batch #16180

andreimatei opened this issue May 26, 2017 · 2 comments
Labels
C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)
Milestone

Comments

@andreimatei
Copy link
Contributor

Currently the tableWriter (and I assume also tableUpdater) does everything in one batch. This can lead to large Raft proposals (and it can run into the kv.raft.command.max_size limit). If the Insert is configured with autocommit, then the batch is first checked against the kv.transaction.max_intents limit.

As a fun fact, it's currently possible to not hit the max_size limit, but subsequently hit the kv.transaction.max_intents limit at commit time. I think this is not ideal since, if all the intents that EndTransaction needs to carry were produced by a single batch, and that batch was applied successfully, the EndTransaction would probably apply successfully too.

I think it'd be a significant improvement if the Insert node would chunk up its writes so that large batches and proposals are avoided.
If we do this, and if we allow parallel execution of batches, there might be sequencing concerns to keep in mind for the UPDATE case - if a single UPDATE stmt updates a row twice, is it specified which one has to win?

Also see #15713

@andreimatei andreimatei added the C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) label May 26, 2017
@andreimatei andreimatei added this to the 1.1 milestone May 26, 2017
@petermattis petermattis modified the milestones: 1.2, 1.1 Aug 17, 2017
@bdarnell bdarnell modified the milestones: 2.0, 2.1 Feb 8, 2018
@jordanlewis
Copy link
Member

@andreimatei did this get finished recently? I heard a rumor...

@andreimatei
Copy link
Contributor Author

yes, closed in #23373

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)
Projects
None yet
Development

No branches or pull requests

4 participants