Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(schema): remove blocking processing indexes and improve processing stats table #130

Merged
merged 1 commit into from
Oct 22, 2020

Conversation

iand
Copy link
Contributor

@iand iand commented Oct 21, 2020

The processing indexes are very slow to create against populated databases. Remove them
and add them back in as part of a later conversion of the processing tables to
hypertables (see #111)

While we are amending this migration, also change the structure of the visor_processing_stats
table. Fixes #120

…g stats table

The processing indexes are very slow to create against populated databases. Remove them
and add them back in as part of a later conversion of the processing tables to
hypertables (see #111)

While we are amending this migration, also change the structure of the visor_processing_stats
table. Fixes #120
@iand
Copy link
Contributor Author

iand commented Oct 21, 2020

This should unblock releasing features that are held off pending this index migration.

@iand iand requested review from placer14 and lanzafame October 21, 2020 12:57
@@ -126,7 +128,7 @@ func (r *ProcessingStatsRefresher) Run(ctx context.Context) error {
}

func (r *ProcessingStatsRefresher) collectStats(ctx context.Context) (bool, error) {
subQueries := []string{statsActors}
subQueries := []string{fmt.Sprintf(statsActors, actorCodeCase)}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this mean we're templating the case statement into each of the sub-select's in the union?
is there a way to select that into a place that can then be directly used in each of the union'd selects directly?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could try something clever like inserting into a temporary table and joining against it, but I'm not sure it's worth it. The case is evaluated once per actor code per subquery (since we have already grouped by code). Perhaps about 120 times which I think is quite low compared to the cost of grouping over 30 million rows.

@iand iand merged commit af6d83f into master Oct 22, 2020
@iand iand deleted the iand/remove-migration-9-indexes branch October 22, 2020 08:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

visor_processing_stats table should have the actor as a separate column
2 participants