-
Notifications
You must be signed in to change notification settings - Fork 23
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
Make room for other database engines #1139
Conversation
Rely on the "created_at" field to perform the search and ordering in database. This requires the indexes to be updated (which was already the case when runnin batches).
@pnax, this is for v2024.1, isn't it? |
yes |
(SELECT count(*) FROM result_entries JOIN test_results ON result_entries.hash_id = test_results.hash_id AND level = ?) AS nb_critical, | ||
(SELECT count(*) FROM result_entries JOIN test_results ON result_entries.hash_id = test_results.hash_id AND level = ?) AS nb_error, | ||
(SELECT count(*) FROM result_entries JOIN test_results ON result_entries.hash_id = test_results.hash_id AND level = ?) AS nb_warning, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks wrong to me but maybe it just me reading it wrong. Doesn't this joined test_results shadow the test_results in the outer select? If it is, doesn't that mean that the count includes all entries for all tests just as long as they have the right level?
@@ -81,7 +81,7 @@ sub create_schema { | |||
) or die Zonemaster::Backend::Error::Internal->new( reason => "PostgreSQL error, could not create 'test_results' table", data => $dbh->errstr() ); | |||
|
|||
$dbh->do( | |||
'CREATE INDEX IF NOT EXISTS test_results__hash_id ON test_results (hash_id)' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't we still need an index for just hash_id? E.g. for the test_progress
RPCAPI method.
Purpose
This PR removes the need to have a primary key defined within the database. For instance Clickhouse does not support it. So some specific code is needed. With this PR, such specific code could be removed and the same SQL queries could be used.
Also it appears that when running batches, the indexes are dropped and create again. But one index was not created as intended and included the
created_at
field. However with this PR, an index using thecreated_at
field is necessary to keep good performance. So the initial index is updated (instead of updating the index in the batch method).Context
This was initially part of #1094, and moved to another PR to avoid changing internal while integrating an experimental feature.
Changes
created_at
field and not theid
fieldHow to test this PR