| Commit message (Collapse) | Author | Age |
|
|
|
| |
As this is used when rendering builds.
|
|
|
|
| |
To help the QA data service prioritise branches over patches.
|
|
|
|
|
|
|
|
|
|
|
| |
This is mostly a workaround for the occasional problems with the guix-commits
mailing list, as it can break and then the data service doesn't learn about
new revisions until the problem is fixed.
I think it's still a generally good feature though, and allows deploying the
data service without it consuming emails to learn about new revisions, and is
a step towards integrating some kind of way of notifying the data service to
poll.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This might be generally useful, but I've been looking at it as it offers a way
to try and improve query performance when you want to select all the
derivations related to the packages for a revision.
The data looks like this (for a specified system and target):
┌───────┬───────┐
│ level │ count │
├───────┼───────┤
│ 15 │ 2 │
│ 14 │ 3 │
│ 13 │ 3 │
│ 12 │ 3 │
│ 11 │ 14 │
│ 10 │ 25 │
│ 9 │ 44 │
│ 8 │ 91 │
│ 7 │ 1084 │
│ 6 │ 311 │
│ 5 │ 432 │
│ 4 │ 515 │
│ 3 │ 548 │
│ 2 │ 2201 │
│ 1 │ 21162 │
│ 0 │ 22310 │
└───────┴───────┘
Level 0 reflects the number of packages. Level 1 is similar as you have all
the derivations for the package origins. The remaining levels contain less
packages since it's mostly just derivations involved in bootstrapping.
When using a recursive CTE to collect all the derivations, PostgreSQL assumes
that the each derivation has the same number of inputs, and this leads to a
large overestimation of the number of derivations per a revision. This in turn
can lead to PostgreSQL picking a slower way of running the query.
When it's known how many new derivations you should see at each level, it's
possible to inform PostgreSQL this by using LIMIT's at various points in the
query. This reassures the query planner that it's not going to be handling
lots of rows and helps it make better decisions about how to execute the
query.
|
|
|
|
| |
I think this might help with queries that don't use the build_server_id.
|
|
|
|
| |
This might help with doing recursive queries on the derivations graph.
|
|
|
|
| |
This helps row count estimates when filtering on system_id and target.
|
|
|
|
|
|
|
|
|
| |
This will hopefully provide a less expensive way of finding out if a scheduled
build is probably blocked by other builds failing or being canceled.
By working this out when the build events are recieved, it should be more
feasible to include information about whether builds are likely blocked or not
in various places (e.g. revision comparisons).
|
| |
|
|
|
|
|
| |
This is so that data.qa.guix.gnu.org can be configured only to query the
branches from the main repository.
|
|
|
|
| |
And also remove the duplicates that have crept in.
|
|
|
|
| |
This helps render the package version range related pages.
|
|
|
|
|
|
|
|
|
|
|
|
| |
And create a proper git_branches table in the process.
I'm hoping this will help with slow deletions from the
package_derivations_by_guix_revision_range table in the case where there are
lots of branches, since it'll separate the data for one branch from another.
These migrations will remove the existing data, so
rebuild-package-derivations-table will currently need manually running to
regenerate it.
|
|
|
|
|
| |
Where hash is not null, since this helps with the fixed output package
derivations query.
|
|
|
|
|
|
| |
Start at least looking for package replacements, and storing the
details (particularly the derivation). I'm looking at doing this so that build
servers using the Guix Data Service can build these derivations.
|
|
|
|
|
|
| |
This index speeds up inserting new entries to the package_metadata table.
Signed-off-by: Christopher Baines <mail@cbaines.net>
|
|
|
|
| |
This is from reading the slow query log on data.guix.gnu.org.
|
|
|
|
|
|
|
|
| |
And use it for the systems in the derivations and package derivations tables.
The primary motivation here is to allow quickly working out what systems the
database contains, and having a small table with just the right data seems a
good way to do that.
|
|
|
|
|
|
| |
This means that these derivations are stored, even if a later part of the
process fails. Having the channel instance derivations stored might help work
out why the failure occurred, or better display information about it.
|
|
|
|
|
|
| |
It has a lot of rows, and this seems to help the query planning for
select-required-builds-that-failed, as I think it helps PostgreSQL better
estimate the row counts that different parts of the query will produce.
|
|
|
|
| |
This is necessary to quickly delete entries from package_derivaitons.
|
|
|
|
|
| |
As it doesn't handle wierdness for statuses, like builds being canceled with a
timestamp of 0.
|
|
|
|
|
| |
This will avoid many queries trying to figure out what the latest build status
is, which will hopefuly simplify queries as well as improving performance.
|
|
|
|
| |
To allow using the Guix Data Service when commits aren't authenticated.
|
|
|
|
| |
As this speeds up deleting derivation_source_files.
|
|
|
|
|
|
| |
I've not used these in many places, to try and avoid hiding deleting data, but
in this case, this will allow more easily deleting the derivation source file
nars, by just deleting the derivation_source_files table entry.
|
|
|
|
|
|
| |
Looking at data for the the patches deployment of the Guix Data Service, these
tables look like they might benefit from vacuuming/analyzing more often, so
adjust the configuration so this will hopefully happen.
|
|
|
|
|
|
|
|
|
|
|
| |
From the normalized one, to the one actually contained within glibc. Recent
versions of glibc also contain symlinks linking the normalized codeset to the
locales with the .UTF-8 ending, but older ones do not.
Maybe handling codeset normalisation for queries would be good, but the locale
values ending in .UTF-8 are more compatible and allow the code to be
simplified. For querying, maybe there should be a locales table which handles
different representations.
|
|
|
|
|
|
|
|
|
|
| |
To avoid the index data being too large.
This was first seen in guix commit 1bb4fd64b7bbe5a17eda6f0ca8105283c038f7c8:
psql-query-error (fatal-error PGRES_FATAL_ERROR ERROR: index row size 2808
exceeds maximum 2712 for index "package_descriptions_locale_description_key"
HINT: Values larger than 1/3 of a buffer page cannot be indexed.
|
|
|
|
| |
Signed-off-by: Christopher Baines <mail@cbaines.net>
|
|
|
|
|
|
|
|
| |
This helps with queries like:
SELECT *
FROM derivation_output_details_sets
WHERE ARRAY[5563227] <@ derivation_output_details_ids;
|
|
|
|
| |
As the Guix Build Coordinator can build one derivation many times.
|
|
|
|
| |
This effectively makes adding build status entries idempotent to some degree.
|
|
|
|
|
|
|
| |
Like Cuirass, or the Guix Data Service. This isn't so necessary with Cuirass,
as the derivation/output are unique identifiers, but for the Guix Build
Coordinator, one derivation/output can be built many times, with potentially
differing results.
|
|
|
|
|
|
| |
The Guix Build Coordinator doesn't record timestamps for events
currently. This is something to fix, but allow for build statuses without
timestamps as they're not necessary.
|
|
|
|
| |
Signed-off-by: Christopher Baines <mail@cbaines.net>
|
|
|
|
| |
Signed-off-by: Christopher Baines <mail@cbaines.net>
|
| |
|
|
|
|
|
| |
This is to allow for build servers where only the substitutes should be
queried, and it shouldn't be assumed that they're running Cuirass.
|
|
|
|
|
| |
This follows on from 79993bfaeff3097d37838bc0636fc20c6fc4283d, disassociating
the relevant derivations from the revisions.
|
| |
|
|
|
|
|
| |
Given that a commit, regardless of what repository it comes from should
contain the same exactly the same data, just track jobs by commit.
|
|
|
|
| |
This greatly improves the performance of the derivation-outputs page.
|
|
|
|
| |
It's been replaced by the package_derivations_by_guix_revision_range table.
|
|
|
|
|
|
|
| |
Rather than just the native system. I'm not quite sure of the value here, as I
guess system tests should behave the same regardless of the way the software
is compiled, but this seems like it could be useful, and being explicit about
the system the derivation is for is good.
|
|
|
|
| |
To allow for deferring it in a transaction when deleting derivations.
|
|
|
|
|
| |
Change target to '' if it matches system, as this matches the updated way of
storing derivations.
|
|
|
|
| |
These are the ones that relate to Guix pull.
|
|
|
|
|
| |
So that you can have the Guix Data Service only pay attention to some of the
branches.
|