Index service_instances.service_plan_id

[will-gant]

A short explanation of the proposed change:

Index the foreign key service_plan_id in the service_instances table.

An explanation of the use cases your change solves

Will lead to faster reads when looking up service instances created from a particular service plan - e.g. when making checks prior to purging a service plan's instances, when deleting and deactivating plans, and when deleting service offerings and spaces.

The above all run service_plan.service_instances (or .service_instances_dataset), which results in the query SELECT * FROM service_instances WHERE (service_instances.service_plan_id = xxx)"

I ran EXPLAIN ANALYZE on that query (using a different service plan id each time in a bash for loop). For a sense of scale, the foundation in question had 1,121 service instances and 255 service plans at the time.

All times are in milliseconds. Here are the results without an index:

	1	2	3	4	5	6	7	8	9	10	Mean
Planning	0.686	0.648	0.818	0.653	0.872	0.681	0.699	0.796	0.875	0.7	0.7428
Execution	0.353	0.422	0.374	0.378	0.424	0.372	0.364	0.344	0.588	0.364	0.3983
Total	1.039	1.07	1.192	1.031	1.296	1.053	1.063	1.14	1.463	1.064	1.1411

And with the index:

	1	2	3	4	5	6	7	8	9	10	Mean
Planning	0.786	0.734	0.984	0.752	0.805	0.74	0.803	0.771	1.018	1.034	0.8427
Execution	0.066	0.062	0.074	0.064	0.085	0.066	0.065	0.071	0.092	0.087	0.0732
Total	0.852	0.796	1.058	0.816	0.89	0.806	0.868	0.842	1.11	1.121	0.9159

So on this relatively small foundation, that slightly increases planning time in return for a five-fold reduction in execution time (20% faster overall). On one of our large foundations, with around 200,000 service instances and 21,000 service plans, planning time was comparable to the above (in fact a bit faster at 0.058ms) while execution was 15x slower, at 17.290ms. That's without the index, as it's an environment where I can't really do manual experiments in the DB, but I think it's fair to expect a much faster query overall.

For context, in that latter environment, service_instances is a 55mb table. The ratio of scans to writes in that table is about 15:1, which I think also weighs in favour of an index.

Links to any other associated PRs

n/a

• I have reviewed the contributing guide

• I have viewed, signed, and submitted the Contributor License Agreement

• I have made this pull request to the main branch

• I have run all the unit tests using bundle exec rake

• I have run CF Acceptance Tests