Also, from what I understand from the pr comments Ionut, the only reason we even need a schema change on the performance datum table is because you want to keep to create a temporary table with a foreign key on performance datum per https://github.com/mozilla/treeherder/pull/6710#discussion_r481867506, in case the multi-commit perf data changes don't work as expected. So, we'd be increasing the RDS instances only for this reason. Could we perhaps find a workaround? Do you need to keep the data for a month in that table, or would running your pr on prototype2 for a week or so without that table (or even a new RDS instance we could spin up temporarily for you) be sufficient for you to feel confident in the performance datum multi-commit changes?
Bug 1654496 Comment 10 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Also, from what I understand from the pr comments Ionut, the only reason we even need a schema change on the performance datum table is because you want to keep to create a temporary table with a foreign key on performance datum per https://github.com/mozilla/treeherder/pull/6710#discussion_r481867506, in case the multi-commit perf data changes don't work as expected. So, we'd be increasing the RDS instances only for this reason. Could we perhaps find a workaround? Do you need to keep the data for a month in that table, or would running your pr on prototype2 for a week or so without that table (and perf sheriffs could use prototype for testing temporarily) be sufficient for you to feel confident in the performance datum multi-commit changes?
Also, from what I understand from the pr comments Ionut, the only reason we even need a schema change on the performance datum table is because you want to keep to create a temporary table with a foreign key on performance datum per https://github.com/mozilla/treeherder/pull/6710#discussion_r481867506, in case the multi-commit perf data changes don't work as expected. So, we'd be increasing the RDS instances only for this reason. Could we perhaps find a workaround? Do you need to keep the data for a month in that table, or would running your pr on prototype2 for a week or so without that table (and the perf team could use prototype for testing temporarily) be sufficient for you to feel confident in the performance datum multi-commit changes?