Performance fix for CoreMessaging_GetMessageConversations and Journal_ListForGroup Procedure

[ChrisHammond]

Summary

Fixes performance issues experienced with CoreMessaging_GetMessageConversations procedure. The where clause for filtering paging could take 5+ minutes to properly return the result set due to the way the query was written. Added additional CTE to not have to calculate the row count range inside of the where clause.

Fixes issue with Journal_ListForGroup procedure where the page size is set, but the result set is less any deleted journal entries, so the page size is almost always greater, and thus you can never "get more" via the get more button. Proc change allows for Row_number to work properly depending on if you want deleted posts or not.

[dnfclas]

All CLA requirements met.

[david-poindexter]

@ChrisHammond have you created a GitHub issue? For a quick reference on the process, see this document.

[ChrisHammond]

I didn't because someone....... @ohine..... told me not to bother in these two cases :D

[ohine]

I am a fan of having a descriptive pull request description instead of just saying fixes #xyz and putting the info in an issue.

[mitchelsellers]

@ChrisHammond Do you have any metrics on the sizes of tables that you used to validate these changes against? I want to make sure we test/validate based on a proper sized data set.

[sleupold]

IMO one major performance issue with CoreMessaging: there is no "delete" option, i.e. the tables are growing indefinately. This also conflicts with GDPR.

[mitchelsellers]

@sleupold I would agree, the size of these tables over time is a concern. At this point if we can get some incremental improvement it would be appreciated and a longer-term review of architecture or removal of data would be welcomed via an additional pull request.

[ChrisHammond]

@mitchelsellers customer that I was addressing the CoreMessaging issue fix for had

~11k records in Messages
~156 unread messages for the user who was attempting to "load more"

When the load more request fired, it would time out server side, manually running the proc with the same parameters would take 5+ minutes.

After my modification, <1 second for result.

[mitchelsellers]

I have tested this change on 3 installations, one small, one medium and one large. This change doe appear to improve performance greatly. I acknowledge that future changes might need more work, but this seems to make a good improvement over today.

[ChrisHammond]

Thanks for the confirmation @mitchelsellers