-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Optimize queries for account_tx to work around SQLite query planner #2312
Conversation
Jenkins Build SummaryBuilt from this commit Built at 20180101 - 05:16:58 Test Results
|
The unit test is failing because the manual filter threw off the LIMIT clause's results. I have to rethink this. |
I rewrote the SQL in the original instead of making a manual filter. It passes unit tests and improves performance. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm no SQL optimization expert, but the new query should generate the same results and looks reasonable.
How big is a full history sqlitedb these days? Is it even still possible? |
👍 |
Nit: Remove the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm honestly a little surprised that the implicit join (FROM AccountTransactions, Transactions
) is faster than the INNER JOIN
used in prefix
, but data don't lie.
👍
@ximinez You're right that the original query should be slightly faster because it only joins on those 2 fields once, whereas the new version essentially takes the union of 2 distinct search queries that each join on those 2 fields. But the query planner for the original version wasn't picking up the index for one or both of the operands of the OR expression in the query. |
This is referenced in https://ripple.com/dev-blog/rippled-version-0-81-0/ but not merged? |
@bradsavon It will get merged into the develop branch, which will turn into 0.90. This was put into the current production code because it will contribute to stability right away. |
Great, thanks for clarification |
In 0.90.0-b3 |
No description provided.