Allow better query plans #4424
Allow better query plans #4424
Conversation
dullbananas
commented
Feb 4, 2024
•
dullbananas
commented
- Change from_collapse_limit and join_collapse_limit from 8 to 11 (later I will make more queries not exceed the limit of 11)
- Change geqo_threshold back to default if the server has a custom value for it, which is important if the custom value is not greater than 11
- Limit connection age to 3 days to prevent use of query plans that use old statistics
|
I tested it with 0 instead of 3 days and the pool still works |
dullbananas
requested review from
Nutomic,
dessalines and
phiresky
as code owners
|
Did you get any performance improvements with these changes? |
| .batch_execute("SET geqo_threshold=12;SET fro_collapse_limit=11;SET join_collapse_limit=11;") | ||
| .await | ||
| .map_err(ConnectionError::CouldntSetupConfiguration)?; | ||
| Ok(conn) |
There was a problem hiding this comment.
Please add some comments what these settings do and why you picked those values. I also think this could cause problems if an admin tries to optimize their db, but changes get silently overwritten by Lemmy.
There was a problem hiding this comment.
I also think this could cause problems if an admin tries to optimize their db, but changes get silently overwritten by Lemmy.
I will eventually make queries not exceed the new collapse limits. Higher values set by admins will make no difference in that case.
There's no measurable changes yet because db_perf currently doesn't run any query that's affected by the changed collapse limits. One potential performance improvement is in PostReportView, which joins 9 or 10 tables. Currently, it needs to join the community_moderator table last, which is very bad for performance. Now, it no longer exceeds the collapse limits, which makes it possible for the query planner to change the join order. I don't expect the connection age limit to improve performance in most cases, but it will be very helpful in some cases where the number of rows in a table increases very quickly from a small amount (which could cause prepared statements to use sequential scans) to a much bigger amount. This reduces the chance of needing to restart the server. |
