Query Reporting: Record auto_explain plans for queries in CI

Since it would be helpful for table partitioning efforts to be able to identify queries that are incompatible with partitioning, and auto_explain plans contain information on whether sub plans were removed, we should record auto_explain plans for queries executed during CI runs.

added to epic &8441 (closed)

@mattkasa, Please add a group or category label to identify issue ownership.

You can refer to the Features by Group handbook page for guidance.

If you are unsure about the correct group, please do not leave the issue without a group label, and refer to GitLab's shared responsibility functionality guidelines for more information on how to triage this kind of issue.

This message was generated automatically. You're welcome to improve it.

This issue was automatically tagged with the label ~"group::product intelligence" by TanukiStan, a machine learning classification model, with a probability of 0.35.

If this label is incorrect, please tag this issue with the correct group label as well as automation:ml wrong to help TanukiStan learn from its mistakes.

If you are unsure about the correct group, please do not leave the issue without a group label. Please refer to GitLab's shared responsibility functionality guidelines for more information on how to triage this kind of issues.

Authors who do not have permission to update labels can leave the issue to be triaged by group leaders initially assigned by TanukiStan

This message was generated automatically. You're welcome to improve it.

added automation:ml label

added automation:ml wrong groupdatabase labels

added devopsdata stores sectioncore platform labels

Setting label(s) Category:Database based on groupdatabase.

added Category:Database label

mentioned in issue gitlab-org/database-team/team-tasks#353 (closed)

@mattkasa could you update the Issue description?

Done, thank you for reminding me

added typemaintenance label

changed the description

@stomlinson and I have started work on this in Use auto_explain to record queries with plans (!122538 - closed)

added workflowin dev label

changed milestone to %16.2

mentioned in issue gitlab-org/database-team/team-tasks#354 (closed)

@dfrazao-gitlab In order to get a better understanding of our throughput and capacity, using issue weights based on merge requests. For this issue, would you consider how many merge requests it may take to implement this, add a comment enumerating them, and add the count as the issue weight? Thanks!

Examples (click to view)

An issue that just needs to update some documentation would be /weight 1 accompanied by a comment:

Just one merge request to documentation

An issue that might be broken out into separate merge requests for database, functional, documentation, and omnibus changes would be /weight 4 accompanied by a comment:

One to gitlab for database changes, one for new functionality, one for documentation changes, and one to omnibus

@dfrazao-gitlab In order to get a better understanding of our throughput and capacity, using issue weights based on merge requests. For this issue, would you consider how many merge requests it may take to implement this, add a comment enumerating them, and add the count as the issue weight? Thanks!

Examples (click to view)

An issue that just needs to update some documentation would be /weight 1 accompanied by a comment:

Just one merge request to documentation

An issue that might be broken out into separate merge requests for database, functional, documentation, and omnibus changes would be /weight 4 accompanied by a comment:

One to gitlab for database changes, one for new functionality, one for documentation changes, and one to omnibus

@dfrazao-gitlab In order to get a better understanding of our throughput and capacity, using issue weights based on merge requests. For this issue, would you consider how many merge requests it may take to implement this, add a comment enumerating them, and add the count as the issue weight? Thanks!

Examples (click to view)

An issue that just needs to update some documentation would be /weight 1 accompanied by a comment:

Just one merge request to documentation

An issue that might be broken out into separate merge requests for database, functional, documentation, and omnibus changes would be /weight 4 accompanied by a comment:

One to gitlab for database changes, one for new functionality, one for documentation changes, and one to omnibus