Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
ImGajeed76
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
8 ms
·
1.
▲
by
ImGajeed76
5mo ago
you should! "go install" it and you're up in a minute.
2.
▲
by
ImGajeed76
5mo ago
i did look into this before writing the post. there's a fossil-users mailing list post by Isaac Jurado where he reported that importing Django took ~20 minutes and importing glibc on a 16GB machine had to be interrupted after a couple
3.
▲
by
ImGajeed76
5mo ago
Thanks! LWN's development cycle reports are incredible and were actually an inspiration. The goal here wasn't to replace that kind of expert analysis but to show what becomes possible when you can just write SQL against the raw hi
4.
▲
Pgit: I Imported the Linux Kernel into PostgreSQL
(oseifert.ch)
1 points
by
ImGajeed76
5mo ago
|
0 comments
5.
▲
I imported the full Linux kernel git history into pgit
(oseifert.ch)
162 points
by
ImGajeed76
6mo ago
|
45 comments
6.
▲
Pgit: I Imported the Linux Kernel into PostgreSQL
(oseifert.ch)
2 points
by
ImGajeed76
6mo ago
|
0 comments
7.
▲
by
ImGajeed76
6mo ago
yeah i get that. sorry if it comes across as too salesy. but keep in mind that pgit was only meant to be a demo of pg-xpatch and wasn't built with beating git in mind. the fact that it's SQL queryable and comes close to git's
8.
▲
by
ImGajeed76
6mo ago
Sounds great! Yeah i have been working on a 3 layer cache in pg-xpatch so its not only in-memory cache but a little more sufisticated and hopefully uses less ram... haha. but its still not quite what i want.
9.
▲
by
ImGajeed76
6mo ago
They are talking about this fossil: https://fossil-scm.org/home/doc/trunk/www/index.wiki
10.
▲
by
ImGajeed76
6mo ago
fire
11.
▲
by
ImGajeed76
6mo ago
haha yeah pretty much. but postgres already solves most of that complexity for you, so you get SQL queryability almost for free.
12.
▲
by
ImGajeed76
6mo ago
yeah totally get that. the main blocker was delta compression. sqlite's extension api made it really slow for custom storage. i either had to do all the compression on the pgit side (and lose native SQL queryability) or just use postgr
13.
▲
by
ImGajeed76
6mo ago
haha, great that you tried! i also imported it multiple times now and it does work. but it's huge. the times actually match quite well, i also had around 3 hours, i'm surprised you managed to do it that fast actually. so yeah, i&#
14.
▲
by
ImGajeed76
6mo ago
thanks! FUSE is actually a really cool idea, hadn't thought about that. would basically let you mount a repo as a filesystem backed by postgres. server side branches and change sets are interesting too, postgres already handles concurr
15.
▲
by
ImGajeed76
6mo ago
good question! the "pgit actual" column tries to compare just the compression algorithms, similar to how the git side only counts the .pack file and not .idx/.rev/.bitmap or filesystem overhead. so both sides strip their
16.
▲
by
ImGajeed76
6mo ago
sounds interesting
17.
▲
by
ImGajeed76
6mo ago
hahaha i feel that
18.
▲
by
ImGajeed76
6mo ago
Yeah, I get that, and I'm fully on your side. SQLite would have been a nice fit. The only downside is the delta compression problem. Creating an extension for SQLite works, but it's slow. I had two options: 1) Do the delta compres
19.
▲
by
ImGajeed76
6mo ago
1) In the case of pgit, the "remote" database is a local docker container 2) You can do more complex analyses faster and easier (you don't need to pipe the git outputs) since it's just SQL but pgit is not meant to replac
20.
▲
by
ImGajeed76
6mo ago
The problem i faced is mostly importing large repos. But normal use should be fine.
21.
▲
by
ImGajeed76
6mo ago
Accessing specific files is very fast. For sure sub second and most of the times its just a few milliseconds
22.
▲
by
ImGajeed76
6mo ago
Yes, you also got analysis commands the AI can use. I just did the prompt example before they existed.
23.
▲
by
ImGajeed76
6mo ago
thanks! but it might still need some releases until it's really good. just don't rely on it ;)
24.
▲
by
ImGajeed76
6mo ago
but the difference between you and an agent is that you naturally know the history of the project if you have worked on it. the AI doesnt.
25.
▲
by
ImGajeed76
6mo ago
I did actually look into writing the extension for duckdb. But similar to SQLite the extension possibilities are not great for what I needed. Though duckdb is a great database.
26.
▲
by
ImGajeed76
6mo ago
in theory yes. you just need to do the full text search across the databases. pgit doesnt support it but at the end its just postgres under the hood.
27.
▲
by
ImGajeed76
6mo ago
so most analyses already have a CLI function you can just call with parameters. for those that don't, in my case, the agent just looked at the --help of the commands and was able to perform the queries.
28.
▲
by
ImGajeed76
6mo ago
sounds great yes. maybe an SQLite version will come in the future
29.
▲
by
ImGajeed76
6mo ago
yeah fossil is great, but can fossil import the linux kernel (already working on the next post)
30.
▲
Show HN: Pgit – A Git-like CLI backed by PostgreSQL
(oseifert.ch)
126 points
by
ImGajeed76
6mo ago
|
60 comments
More ›