Add/Remove Indexes - Allocator Table

[kaysiz]

Purpose

We have missing and unused indexes on allocator table.

closes: #1117

Approach

Open Questions and Pre-Merge TODOs

Learning

Types of changes

• Bug fix (non-breaking change which fixes an issue)

• New feature (non-breaking change which adds functionality)

• Breaking change (fix or feature that would cause existing functionality to change)

Reviewer, please remember our guidelines:

• Be humble in the language and feedback you give, ask don't tell.
• Consider using positive language as opposed to neutral when offering feedback. This is to avoid the negative bias that can occur with neutral language appearing negative.
• Offer suggestions on how to improve code e.g. simplification or expanding clarity.
• Ensure you give reasons for the changes you are proposing.

[wendelfabianchinsamy]

@kaysiz have we confirmed that the queries missing these indices are in fact using these indices in the query execution plan?

[digitaldogsbody]

Good question Wendel!

I think if Rails is not smart enough to have done this and we have to do it manually, it can be a separate piece of work/PR and doesn't need to be a blocker to merging this.

[wendelfabianchinsamy]

Cool cool. One thing we may notice is we may get a bunch of index scans instead of index seeks. Since the query executor will still need to go back into the table fetch relevant information (columns not included in the index). MySql will only use one index per query per table so index_allocator_deleted_at would be used or index_allocator_role_name will be used or neither if the query executor thinks it's unnecessary.

[wendelfabianchinsamy]

@kaysiz something for us to keep in mind, adding additional indices will have two side-effects:

1. We will increase the page size as we have to store additional indices (increased storage - probably less of an issue but I thought I'd add this as a heads up)
2. We could have a detrimental effect on writes since each write will also have to update the indices.

Just thought I'd add these as a comment just so we could keep an eye on any write performance degradation or if we see a uptick in RDS storage usage.

[kaysiz]

@kaysiz something for us to keep in mind, adding additional indices will have two side-effects:

1. We will increase the page size as we have to store additional indices (increased storage - probably less of an issue but I thought I'd add this as a heads up)
2. We could have a detrimental effect on writes since each write will also have to update the indices.

Just thought I'd add these as a comment just so we could keep an eye on any write performance degradation or if we see a uptick in RDS storage usage.

@wendelfabianchinsamy We are doing more reading than writing to the table, we will monitor after deployment if there are any performance issues, but this should improve our read speed.

[ashwinisukale]

I guess we might need this index, because we are using this column in serializer at many places, you can take a look at this commit for reference eeb811c

[kaysiz]

@ashwinisukale unfortunately we are not using the column to fetch any data(that is either .where, find_by or order_by), inside the serialiser it is used to conditionally include the the attribute.

[ashwinisukale]

I have one comment regarding globus_uuid column index. Otherwise code looks good.