| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
Switch from using a recursive query to doing a breath first search through the
graph of derivations, as I think PostgreSQL wasn't doing a great job of
planning the recursive queries (it would overestimate the rows involved, and
prefer sequential scans for the derivation_outputs table).
|
|
|
|
| |
Use larger batches and more efficient duplicate deletion.
|
|
|
|
| |
Since this speeds up the response if you don't need the nar information.
|
| |
|
|
|
|
| |
Which should reduce the peak memory usage.
|
|
|
|
| |
As that better reflects what it does.
|
|
|
|
|
|
|
|
|
|
| |
Previously it would compute a long list of strings, potentially more than
100,000 elements long, then split this string up and insert it in chunks. Only
then could memory be freed.
This new approach builds the strings in batches for the insertion query, then
moves on to the next batch. This should mean that more memory can be freed and
reused along the way.
|
|
|
|
| |
This might help when there's lots of derivations to insert.
|
|
|
|
| |
To avoid making a very large query when inserting lots of derivations.
|
| |
|
|
|
|
| |
To avoid one massive query.
|
|
|
|
| |
To avoid one massive query.
|
|
|
|
| |
In update-derivation-ids-hash-table!.
|
|
|
|
|
| |
Rather than querying for the output ids one by one and then running an insert
query for each derivation, perform the task with a single insert query.
|
| |
|
|
|
|
|
|
| |
Rather than creating vhashes, just update the hash table that is used as a
cache, and query that. This should speed things up and reduce memory usage
when loading derivations.
|
|
|
|
|
|
| |
Split the recursive part of the query from the non-recursive part, since
PostgreSQL doesn't do a great job of estimating the number of rows which will
come back from the recursive part, and thus generates a bad plan.
|
|
|
|
| |
Previously, the VALUES list wasn't being generated properly.
|
|
|
|
|
| |
Source file nars weren't always recorded, so this will help backfill that
data (which enables providing substitutes for those derivations).
|
|
|
|
| |
One was added in e81cf4e79a6e297db0ae2a9c39eab495e7e204f0.
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
As that table is always included in the query.
|
|
|
|
| |
The parameters must be strings rather than numbers.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
comparison.scm: return query data for derivation comparison as an alist,
instead of list.
html.scm: Access derivation differences data using assq-ref.
controller.scm: remove mapping for outputs/inputs/sources.
utils.scm: add group-to-alist/vector function.
Signed-off-by: Christopher Baines <mail@cbaines.net>
|
| |
|
| |
|
|
|
|
| |
This removes the need to hardcode some values in the code.
|
|
|
|
|
|
|
|
| |
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 branches aren't omitted if the latest commit hasn't been processed
yet.
|
|
|
|
|
|
| |
This might be useful for working out when a non-master branch contains a newer
version of a package, or someone has sent in a patch for a newer version
already.
|
|
|
|
| |
This should be useful for looking at when system tests break.
|
|
|
|
|
| |
This should not be necessary, but currently the database isn't used to find
out the valid system values.
|
| |
|
| |
|
|
|
|
| |
When the latest revisions haven't been processed successfully yet.
|
|
|
|
| |
Look at the job succeeded_at, rather than the guix_revisions.id field.
|
| |
|
| |
|
|
|
|
|
| |
This was broken when the guix_revisions entry started being added before the
final commit.
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
As I want to remove the field from the database.
|
|
|
|
| |
Rather than scheduled builds as well, as that's not useful information.
|
| |
|
| |
|
| |
|
| |
|
| |
|