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
Make faster engine response on cancel\shutdown signals when scanning long list of pointer pages [CORE5727] #5993
Comments
Modified by: @hvladassignee: Vlad Khorsun [ hvlad ] |
Commented by: @hvlad Currently there is two known cases when engine could not response fast enough on cancel attachment or shutdown signal: |
Commented by: @pavel-zotov Please, consider also inscrutable behaviour of SIMILAR TO operator. I've repeated again "mistic statement" from there, and all the same: could not get reply from "gfix -shut full -force 0" for ~ 2 minutes on Windows 8.1, recent FB 4.0 build. |
Modified by: @hvladstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 4.0 Beta 1 [ 10750 ] Fix Version: 3.0.4 [ 10863 ] |
Commented by: @pavel-zotov Vlad, i know, of course. I mean: "engine could not response fast enough" - not only of those two reasons that you have mentioned above. Beside very poor performance, changing DB state to full shutdown is impossible during valuable time. |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Resolved [ 5 ] QA Status: No test => Cannot be tested Test Details: Tried to reproduce on 65 Gb (oltp-emul) and 500+ gb (real system) databases, repeat two times: with FileSystemCacheThreshold greater than and less than DefaultDBCachePages. On Firebird where this fix was not applied (2.5.7, build: 27086) time of preparing query was very small, less than 700 ms. Can not compare such value with smth other. Sent several letters to hvlad (last: 05-feb-2018 23:56). |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Closed [ 6 ] |
Submitted by: @hvlad
Commits: 9bd8685 b0b65ef
====== Test Details ======
Tried to reproduce on 65 Gb (oltp-emul) and 500+ gb (real system) databases, repeat two times: with FileSystemCacheThreshold greater than and less than DefaultDBCachePages.
table in bot cases contained about 1600 PP. Linux page cache was flushed and cleared before each run of .sql
On Firebird where this fix was not applied (2.5.7, build: 27086) time of preparing query was very small, less than 700 ms. Can not compare such value with smth other.
Sent several letters to hvlad (last: 05-feb-2018 23:56).
The text was updated successfully, but these errors were encountered: