| 10 Jan 2022 |
 @grahamc:nixos.org | das_j: I'm inclined to just hit merge on this PR. | 18:58:52 |
 das_j | I won't keep you from it ;) | 19:05:30 |
| das_j | we have these blessed PRs that we've been running for some time now:
# restart buttons
"836" = "sha256-BKtSgJQarVxkveeU4QqtOtqpgq76826COvL5BdRPvbc=";
# GitInput: Avoid fetch if rev is available
"868" = "sha256-dTFGWhfiANs5Z5ScmZxFaCZPZfAVBJOceEOvVMHShSw=";
# queue-runner status in topbar
"869" = "sha256-iFpMV4Z5VE7YmvnAHAydUQYk0FNKNarPYqRHEAuT4/w=";
# tailon
"957" = "sha256-M7MiBcG3DCezdyg7HgNnLWPlJcU2NgLUyI1LXlihXrU=";
# improved UI
"965" = "sha256-VJ6JwPFWwT5qy+dBsqecnvKtmHZ+VemCqYE6EmiWQQM=";
# print whats being evaluated
"1094" = "sha256-U6m8XySqZ/j6qYWGvSeZ7zLip25NGk4PREMo4HJS/X8=";
# fix warnings and logging
"1098" = "sha256-RD9zvAjzVLFq0hzZiFg7JrPvLdlwL249wQLlx9OKU4s=";
| 19:05:57 |
| @grahamc:nixos.org | https://github.com/NixOS/hydra/pull/1101 is in prep to this commit: https://github.com/NixOS/hydra/commit/6f387b363cc9b687c859756d153908add8065149 which proposes sending cached_build_finished and cached_build_queued events to be able to send status events externally in a non-spammy way | 21:56:50 |
|  @ius:nltrix.net joined the room. | 23:20:37 |
| 11 Jan 2022 |
| @ius:nltrix.net | Has anyone investigated why the search is so slow (particularly on NixOS hydra, but I guess it's a general defect at least in theory)? | 00:51:33 |
| @grahamc:nixos.org | I've done a lot of research in to it, and there are a bunch of options on making it faster | 00:53:09 |
| @grahamc:nixos.org | it depends on what you're searching for | 00:53:32 |
| @ius:nltrix.net | Perhaps it's in part my novice interactions with Hydra (I hardly know 'er), but it's not helping in getting me familiar. (end of rant part) | 00:54:35 |
| @ius:nltrix.net | Now I did do some sleuthing, and found e.g. https://github.com/NixOS/hydra/pull/854 | 00:54:52 |
| @grahamc:nixos.org | yeah, and the comments on https://github.com/NixOS/hydra/pull/853 include some of my research | 00:55:11 |
| @grahamc:nixos.org | in general I haven't worked on making them faster because of time limits :) | 00:55:25 |
| @ius:nltrix.net | Yes, I saw that ticket as well. | 00:55:38 |
| @ius:nltrix.net | Anyhow, it's exactly the issue I'm experiencing. Times out on buildoutputs.path ILIKE ?, which relates to: https://github.com/NixOS/hydra/blob/master/src/lib/Hydra/Controller/Root.pm#L477-L487 | 00:56:38 |
| @grahamc:nixos.org | what is your use case for search? | 00:57:00 |
| @ius:nltrix.net | Both seem to involve derivation paths, so I'm wondering why there's a LIKE in the first place? | 00:57:11 |
| @ius:nltrix.net | I wanted to search a nix path in this case | 00:57:22 |
| @ius:nltrix.net | To be really precise, my input was: yah9mf7x2ycalb28gg9ximh49g0akkrn-audit-riscv64-unknown-linux-gnu-2.8.5-bin | 00:57:54 |
| @grahamc:nixos.org | cool | 00:58:15 |
| @grahamc:nixos.org | yeah, I think patch adding LIKE was a bit of a mistake, using a btree with a proper comparison op should make it a lot faster | 00:58:35 |
| @ius:nltrix.net | Looks like that's not really compatible with LIKE | 00:58:40 |
| @grahamc:nixos.org | it does work with LIKE, but not with several hundred million builds | 00:58:52 |
| @ius:nltrix.net | Because, if I understand psql docs correctly, it'll result in a seq scan | 00:59:07 |
| @grahamc:nixos.org | exactly | 00:59:16 |
| @grahamc:nixos.org | but again a LIKE is actually fine if it is a suffix only like, ie: LIKE "/nix/store/xxxx%" | 00:59:37 |
| @grahamc:nixos.org | luckily nix store paths are very predictable, so this could be detected | 00:59:55 |
| @ius:nltrix.net | Yeah, but you'd want to support searching for yah9mf7x2ycalb28gg9ximh49g0akkrn as well ideally | 01:00:05 |
| @grahamc:nixos.org | yeah, exactly | 01:00:21 |
| @grahamc:nixos.org | so we could identify it contains a Nix store path's hash and prefix it with /nix/store/ and append a % | 01:00:34 |
| @ius:nltrix.net | So which made me wonder, wouldn't it help to extract the hash using a regex, and match using equals, so you can use the HASH index? | 01:00:47 |
