Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Better JIT for Postgres

github.com

Post reply on HN
Print view View original

111–116 of 116 posts

Re: Better JIT for Postgres

#111

Post by vladich »

menaerus wrote: post #109
vladich wrote: post #108

Earlier quoted context omitted.

That's all great, but sadly impractical. I looked at one of the first statements: > GenDB is an LLM-powered agentic system that decomposes the complex end-to-end query processing and optimization task into a sequence of smaller and well-defined steps, where each step is handled by a dedicated LLM agent. And knowing typical LLM latency, it's outside of the realm of OLTP and probably even OLAP. You can't wait tens of s…

No, that's not how I believe they intended it to work. They generate the workload-specific engine up-front and not when the query arrives.

Considering it's just s single Phd student who does this work, I don't believe such a task can be realistically accomplished, even as a PoC / research.

Re: Better JIT for Postgres

#112

Post by menaerus »

vladich wrote: post #110
menaerus wrote: post #109

Earlier quoted context omitted.

No, that's not how I believe they intended it to work. They generate the workload-specific engine up-front and not when the query arrives.

Then why they write the opposite?

If you look into the results, you will see that they are able to execute 5x TPC-H queries in ~200ms (total). The dataset is not large it is rather small (10GB) but nonetheless, you wouldn't be able to run 5 queries in such a small amount of time if you had to analyze the workload, generate the code, build indices, start the agents/engine and retrieve the results. I didn't read the whole paper but this is why I think your understanding is wrong.

Re: Better JIT for Postgres

#113

Post by menaerus »

vladich wrote: post #111
menaerus wrote: post #109

Earlier quoted context omitted.

No, that's not how I believe they intended it to work. They generate the workload-specific engine up-front and not when the query arrives.

Considering it's just s single Phd student who does this work, I don't believe such a task can be realistically accomplished, even as a PoC / research.

Why not? Even without LLMs it is technically feasible to build custom database engine that performs much better than general database kernels. And we see this happening all the time, with timeseries, BLOBs, documents, OLTP, OLAP, logging etc.

The catch is obviously that the development is way too expensive and that it takes a lot of technical capability which isn't really all that common. The novelty which this paper presents is that these two barriers might have come to an end - we can use LLMs and agents to build custom database engines for ourselves™ and our™ specific workloads, very quickly and for a tiny fraction of development price.

Re: Better JIT for Postgres

#114

Post by vladich »

menaerus wrote: post #112
vladich wrote: post #110

Earlier quoted context omitted.

Then why they write the opposite?

If you look into the results, you will see that they are able to execute 5x TPC-H queries in ~200ms (total). The dataset is not large it is rather small (10GB) but nonetheless, you wouldn't be able to run 5 queries in such a small amount of time if you had to analyze the workload, generate the code, build indices, start the agents/engine and retrieve the results. I didn't read the whole paper but this is why I think…

If they count only query execution time, not everything else, it would make sense though. It also could be practical, if your system runs just a few predefined and very optimized queries.

Re: Better JIT for Postgres

#115

Post by menaerus »

vladich wrote: post #114
menaerus wrote: post #112

Earlier quoted context omitted.

If you look into the results, you will see that they are able to execute 5x TPC-H queries in ~200ms (total). The dataset is not large it is rather small (10GB) but nonetheless, you wouldn't be able to run 5 queries in such a small amount of time if you had to analyze the workload, generate the code, build indices, start the agents/engine and retrieve the results. I didn't read the whole paper but this is why I think…

If they count only query execution time, not everything else, it would make sense though. It also could be practical, if your system runs just a few predefined and very optimized queries.

To my understanding this is akin to what profile-guided optimization (PGO) in C or C++ does.

Re: Better JIT for Postgres

#116

Post by aengelke »

Asm2D wrote: post #78
aengelke wrote: post #38

Earlier quoted context omitted.

> It's very difficult to do low-latency queries if you cannot cache the compiled code This is not too difficult, it just requires a different execution style. Salesforce's Hyper for example very heavily relies on JIT compilation, as does Umbra [1], which some people regard as one of the fastest databases right now. Umbra doesn't cache any IR or compiled code and still has an extremely low start-up latency; an interpr…

If I recall research papers regarding Umbra it's also using AsmJit as a JIT backend, which means that theoretically the compilation times would be comparable if you only consider code emitting overhead. The problem will always be queries where the compilation is orders of magnitude more expensive than the query itself. I can imagine indexed lookup of 1 or few entries, etc... Accessing indexed entries like these are v…

I'm a bit late, but: Umbra doesn't use AsmJIT anymore since many years, it was too slow.
Post reply on HN