Skip to content

PS-10232 [8.0]: Fix performance regression by limiting rows_in_buffer to query LIMIT #5774

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.

Sign up for GitHub

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

Draft
inikep wants to merge 1 commit into
base: 8.0
Choose a base branch
from
+9 −0
Draft

PS-10232 [8.0]: Fix performance regression by limiting rows_in_buffer to query LIMIT #5774

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions sql/sql_executor.cc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -100,6 +100,7 @@
#include "sql/sql_const.h"
#include "sql/sql_delete.h"
#include "sql/sql_executor.h"
#include "sql/sql_lex.h" // Query_block
#include "sql/sql_list.h"
#include "sql/sql_optimizer.h" // JOIN
#include "sql/sql_resolver.h"
Expand Down Expand Up @@ -739,6 +740,14 @@ bool set_record_buffer(TABLE *table, double expected_rows_to_fetch) {
const ha_rows local_max_rows = (MAX_RECORD_BUFFER_SIZE / record_size);
rows_in_buffer = std::clamp(rows_in_buffer, min_rows, local_max_rows);
}

// Adjust rows_in_buffer based on SELECT ... LIMIT
Query_block *q_block = current_thd->lex->current_query_block();
if (q_block && q_block->select_limit) {
ulonglong select_limit =
std::max<ulonglong>(q_block->select_limit->val_uint(), 2);
rows_in_buffer = std::min(rows_in_buffer, select_limit);
}
Copy link

@dinodork dinodork Dec 4, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The solution works, and I notice a speedup of about a factor three. I don't see any serious problems with it. It's not ideal that the executor peeks into the AST tree, however. My take on the coding pattern is that this type of information should be supplied by the iterator. This is probably something they would pick on if we proposed the patch upstream.

Before the regression, set_record_buffer() would cap the number of rows in the buffer at max_rows. So a more conservative approach would be to reintroduce that cap instead of peeking at the LIMIT, I guess?

What do you think?

}

// After adjustments made above, we still need a minimum of 2 rows to
Expand Down