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
Improve GBAK restore performance (records insertion) [CORE3433] #3795
Comments
Modified by: @asfernandesassignee: Adriano dos Santos Fernandes [ asfernandes ] |
Commented by: @dyemanov I've changed the title to better reflect the goal of this fix. There are other possible improvements, e.g. related to index creation performance, and it'd be better to have these changes outlined/logged as separate items. |
Modified by: @dyemanovsummary: Improve GBAK restore performance => Improve GBAK restore performance (records insertion) |
Modified by: @asfernandesstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 2.5.1 [ 10333 ] Fix Version: 3.0 Alpha 1 [ 10331 ] |
Commented by: @alexeykovyazin Hello, Can I ask to back port it to 2.1.5? Regards, |
Commented by: Thomas Steinmaurer (tsteinmaurer) I would also like to ask whether it is possible to back port this improvement into 2.1.5. Thanks! |
Commented by: @asfernandes Probably yes. I'll check it. |
Commented by: @asfernandes Backported to 2.1.5. |
Modified by: @asfernandesFix Version: 2.1.5 [ 10420 ] |
Commented by: Thomas Steinmaurer (tsteinmaurer) Great! |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Submitted by: @asfernandes
Relate to CORE3802
There is a simple change which makes it much faster, tested with Linux 2.5 embedded restore:
Two databases, with two different tables filled with 2,000,000 records:
create table t1 (n1 integer);
create table t10 (n1 integer, n2 integer, n3 integer, ..., n10 integer);
----------------------
Restore timings:
T1: 14.5s
T10: 20.5s
Improved gbak timings:
T1: 9.7s
T10: 14.7s
----------------------
GBAK builts a BLR in the following way:
blr_receive
blr_store
...
Then calls isc_start_and_send N (records) time.
My change creates this BLR:
blr_loop
blr_receive
blr_store
...
Calls isc_start_and_send first time then N-1 isc_send.
Commits: b269d8b bf51ab2 e53330f
The text was updated successfully, but these errors were encountered: