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

Improve GBAK restore performance (records insertion) [CORE3433] #3795

Closed
firebird-automations opened this issue Apr 8, 2011 · 13 comments
Closed

Comments

@firebird-automations
Copy link
Collaborator

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @asfernandes

assignee: Adriano dos Santos Fernandes [ asfernandes ]

@firebird-automations
Copy link
Collaborator Author

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.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

summary: Improve GBAK restore performance => Improve GBAK restore performance (records insertion)

@firebird-automations
Copy link
Collaborator Author

Modified by: @asfernandes

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.5.1 [ 10333 ]

Fix Version: 3.0 Alpha 1 [ 10331 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @alexeykovyazin

Hello,

Can I ask to back port it to 2.1.5?
There are some big databases running on 2.1.4 (up to 400Gb), and having several % of improvement will save many minutes of maintenance.

Regards,
Alexey Kovyazin
http://www.ibsurgeon.com

@firebird-automations
Copy link
Collaborator Author

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!

@firebird-automations
Copy link
Collaborator Author

Commented by: @asfernandes

Probably yes. I'll check it.

@firebird-automations
Copy link
Collaborator Author

Commented by: @asfernandes

Backported to 2.1.5.

@firebird-automations
Copy link
Collaborator Author

Modified by: @asfernandes

Fix Version: 2.1.5 [ 10420 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Thomas Steinmaurer (tsteinmaurer)

Great!

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue relate to CORE3802 [ CORE3802 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Closed [ 6 ] => Closed [ 6 ]

QA Status: Cannot be tested

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment