| 2 Aug 2023 |
 raitobezarius | It's like having 4 weeks of free time and being bored no? | 17:52:19 |
 Rick (Mindavi) | I guess forking or buying in Graham is also part of the story :) but yeah, sure | 17:57:22 |
| raitobezarius | Let's explicitly have Graham in the loop then | 18:01:17 |
| raitobezarius | So we can decide | 18:01:19 |
| raitobezarius | Forking is fine I suppose as Hydra is not receiving active development | 18:01:28 |
 K900 (deprecated) | I'd be very interested in rewriting Hydra FWIW | 18:01:55 |
| K900 (deprecated) | Though I'm probably more interested in the queue runner bits | 18:02:05 |
| raitobezarius | hahhaha it's such a shame you were not here in Munich when das_j presented us with | 18:05:56 |
| raitobezarius | https://github.com/NixOS/hydra/blob/master/src/hydra-queue-runner/hydra-queue-runner.cc#L284-L312 | 18:06:49 |
 das_j | In reply to @raitobezarius:matrix.org
(I don't really care about either Rust or Python or whatever lang, just something that people can usually grok) Please don't let it be python | 18:06:58 |
| raitobezarius | or was it linus? | 18:06:59 |
| raitobezarius | In reply to @janne.hess:helsinki-systems.de
Please don't let it be python why? :p | 18:07:04 |
| raitobezarius | I don't think the web performance matters, does it? | 18:07:09 |
| raitobezarius | also without GIL it goes faaaaaaaast | 18:07:17 |
| raitobezarius | plus what matters is getting right database query honestly, so good ORM is the most important thing (?) | 18:07:31 |
| das_j | In reply to @raitobezarius:matrix.org
why? :p Upside of a proper language: it's fast and you can also use it to replace the code that links against nix | 18:07:40 |
| K900 (deprecated) | I vote Rust because the next obvious step would be to rip out cppnix and replace it with tvix-eval | 18:08:01 |
| K900 (deprecated) | Also my guess would be that the queries we actually care about are non-ORM-able | 18:08:18 |
| raitobezarius | I mean I want to do Rust too but I just don't want to present myself as a basic RIIR person | 18:08:21 |
| K900 (deprecated) | But what if you are | 18:08:29 |
| raitobezarius | In reply to @k900:conduit.0upti.me
Also my guess would be that the queries we actually care about are non-ORM-able like the one where you get a free ID right | 18:08:29 |
| K900 (deprecated) | Like I'm expecting the fast way of doing things to be some select-for-update nonsense | 18:08:53 |
| das_j | I think a good concept to replace the web thingie would be to write an API server and call that api from the current web pages. This way we can port feature after feature and end up with a CSR application and a new API that is more complete than the current one | 18:09:30 |
| * raitobezarius In reply to @janne.hess:helsinki-systems.de
I think a good concept to replace the web thingie would be to write an API server and call that api from the current web pages. This way we can port feature after feature and end up with a CSR application and a new API that is more complete than the current one nods | 18:09:38 |
| das_j | (replacing perl with nginx in the end) | 18:09:42 |
| raitobezarius | In reply to @k900:conduit.0upti.me
Like I'm expecting the fast way of doing things to be some select-for-update nonsense the biggest problem I have identified IMHO is the builds table | 18:09:54 |
| raitobezarius | and I think the trivial solution is just to partition it | 18:10:02 |
| raitobezarius | Planning Time: 1.121 ms
JIT:
Functions: 20
Options: Inlining true, Optimization true, Expressions true, Deforming true
Timing: Generation 11.320 ms, Inlining 1887.909 ms, Optimization 239.903 ms, Emission 327.814 ms, Total 2466.946 ms
Execution Time: 39210.169 ms
| 18:10:22 |
| das_j | We talked about that and I have no valuable input as my knowledge about that isn't too good | 18:10:27 |
| raitobezarius | here's the cost of a explain analyze select count(*) from builds; | 18:10:30 |
