Improve index performance on Entity Framework persisters - #5881
Merged
Conversation
rbev
force-pushed
the
missing-indexes
branch
from
September 11, 2026 01:33
9798bf1 to
3b359b9
Compare
rbev
changed the title
rbev
marked this pull request as ready for review
September 11, 2026 04:15
rbev
enabled auto-merge
September 11, 2026 08:04
johnsimons
approved these changes
Sep 13, 2026
johnsimons
left a comment
johnsimons
left a comment
Member
There was a problem hiding this comment.
just a couple of comments to consider
| // ingestion rule. EnclosedMessageTypes' first comma token is a type's full name, so the cap can | ||
| // only ever bite on pathological generic names, where a truncated sort key still sorts and | ||
| // groups consistently. | ||
| static string? TruncateForColumn(string? value) => |
Member
There was a problem hiding this comment.
Should the truncate remove the first parts?
In other words, given the type name includes first the namespace, would it make sense to prioritise the class name, hence we start tirmming from left to right?
Contributor
Author
There was a problem hiding this comment.
I'd say a 450char type name is extremely unlikely, it's almost double the windows file path limit, but yes that's probably a better choice.
Comment on lines
+56
to
+57
| public string Id { get; set; } = null!; | ||
| public string Type { get; set; } = null!; |
Member
There was a problem hiding this comment.
should these be marked as required?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request introduces new and optimized database indexes to both the SQL Server and PostgreSQL EF Core persistence layers, aiming to improve the performance of queries on failed messages and failure groups. The changes include adding covering indexes (with INCLUDE columns) for key aggregate queries, introducing new indexes to support sorting and filtering in the UI, and enforcing indexable column lengths for message types. These enhancements are reflected in both the migration files and the EF Core model configuration.
Database Indexing Improvements
Added covering indexes (with INCLUDE columns) to the
Status, LastModifiedindex onFailedMessagesand theType, GroupIdindex onFailedMessageGroupsin both SQL Server and PostgreSQL providers, improving index-only scan performance for group aggregate queries. [1] [2] [3] [4] [5] [6] [7] [8]Added new indexes to
FailedMessagesfor(Status, LastTimeOfFailure)and(Status, MessageType, UniqueMessageId)to support efficient sorting and filtering in the failed messages UI. [1] [2] [3] [4] [5] [6] [7]Schema and Model Changes
MessageTypecolumn onFailedMessagesto have a maximum length of 450 characters (from unlimited text) to allow indexing and prevent issues on SQL Server and PostgreSQL. [1] [2] [3] [4] [5]Documentation and Comments
Query Logic Update
GroupsDataStoreto use the new optimized method for fetching unresolved groups, aligning with the new index structures.These changes collectively improve query performance for key recoverability and failed message scenarios, and ensure the schema is optimized for both SQL Server and PostgreSQL backends.