Fix previous deployment fetches wrong deployment
What does this MR do?
While we were investigating #321032 (closed), we realized that the previous_deployment
method actually doesn't return the previous deployment. It actually returns the other-but-latest deployment.
This MR fixes the outstanding issue.
Related #321032 (closed)
Query Performance implication
@mattkasa That's good question. This change actually also optimizes the query performance.
Here is the current plan:
Limit (cost=0.57..4.45 rows=1 width=139) (actual time=8.236..8.238 rows=0 loops=1)
Buffers: shared read=4
I/O Timings: read=8.181
-> Index Scan using index_deployments_on_environment_id_and_id on public.deployments (cost=0.57..667.53 rows=172 width=139) (actual time=8.233..8.234 rows=0 loops=1)
Index Cond: (deployments.environment_id = 39)
Filter: ((deployments.id <> 124) AND ((deployments.ref)::text = 'master'::text))
Rows Removed by Filter: 0
Buffers: shared read=4
I/O Timings: read=8.181
and here is the new plan:
Limit (cost=0.57..3.59 rows=1 width=139) (actual time=8.884..8.885 rows=0 loops=1)
Buffers: shared hit=3 read=4
I/O Timings: read=8.755
-> Index Scan using index_deployments_on_environment_id_status_and_id on public.deployments (cost=0.57..3.59 rows=1 width=139) (actual time=8.881..8.881 rows=0 loops=1)
Index Cond: ((deployments.environment_id = 39) AND (deployments.status = 2) AND (deployments.id < 124))
Buffers: shared hit=3 read=4
I/O Timings: read=8.755
Notice that Filter: ((deployments.id <> 124) AND ((deployments.ref)::text = 'master'::text))
is quite expensive that likely takes long time when an environment has a lot of deployments. This is because we don't have effective index on the ref
column.
The new plan performs one index scan with index_deployments_on_environment_id_status_and_id
and doesn't perform any sequential filtering. This assures that the query will stay performant regardless of the deployments count on an environment.
Screenshots (strongly suggested)
Does this MR meet the acceptance criteria?
Conformity
-
📋 Does this MR need a changelog?-
I have included a changelog entry. -
I have not included a changelog entry because _____.
-
-
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team