We have everything optimized, and yet somehow DB queries need to be "interpreted" at runtime. There's no reason for DB queries to not be precompiled.
The "byte-code" coming from the query planner typically only has a handful of steps in a linear sequence. Joins, filters, and such. But the individual steps can be very costly.<p>So there is not much to gain from JITing the query plan execution only.<p>JITing begins to make more sense, when the individual query plan steps (join, filter, ...) themselves be specialized/recompiled/improved/merged by knowing the context of the query plan.
This is a neat idea. I want to take it further and precompile the entire DBMS binary for a specific schema.
Many SQL engines have JIT compilers.<p>The problems related to PostgreSQL are pretty much all described here. It's very difficult to do low-latency queries if you cannot cache the compiled code and do it over and over again. And once your JIT is slow you need a logic to decide whether to interpret or compile.<p>I think it would be the best to start interpreting the query and start compilation in another thread, and once the compilation is finished and interpreter still running, stop the interpreter and run the JIT compiled code. This would give you the best latency, because there would be no waiting for JIT compiler.
> It's very difficult to do low-latency queries if you cannot cache the compiled code<p>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 interpreter exists but is practically never used.<p>Postgres is very robust and very powerful, but simply not designed for fast execution of queries.<p>Disclosure: I work in the group that develops Umbra.<p>[1]: <a href="https://umbra-db.com/" rel="nofollow">https://umbra-db.com/</a>
<i>> I think it would be the best to start interpreting the query and start compilation in another thread</i><p>This technique is known as a "tiered JIT". It's how production virtual machines operate for high-level languages like JavaScript.<p>There can be many tiers, like an interpreter, baseline compiler, optimizing compiler, etc. The runtime switches into the faster tier once it becomes ready.<p>More info for the interested:<p><a href="https://ieeexplore.ieee.org/document/10444855" rel="nofollow">https://ieeexplore.ieee.org/document/10444855</a>
See prepared statements.
Postgresql uses a process per connection model and it has no way to serialize a query plan to some form that can be shared between processes, so the time it takes to make the plan including JIT is very important.<p>Most other DB's cache query plans including jitted code so they are basically precompiled from one request to the next with the same statement.
What do you mean ? Cause the obvious thing is a shared cache and if there is one thing the writers of a db know it is locking
> and it has no way to serialize a query plan to some form that can be shared between processes<p><a href="https://www.postgresql.org/docs/current/parallel-query.html" rel="nofollow">https://www.postgresql.org/docs/current/parallel-query.html</a><p>"PostgreSQL can devise query plans that can leverage multiple CPUs in order to answer queries faster."
> However, standard LLVM-based JIT is notoriously slow at compilation. When it takes tens to hundreds of milliseconds, it may be suitable only for very heavy, OLAP-style queries, in some cases.<p>I don't know anything here, but this seems like a good case for ahead of time compilation? Or at least caching your JIT results? I can image much of the time, you are getting more or less the same query again and again?
Yes.<p>Some years ago we ported some code from querying out the data and tallying in Python (how many are in each bucket) to using SQL to do that. It didn't speed up the execution. I was surprised by that, but I guess the Postgres interpreter is roughly the same speed as Python, which when you think about it perhaps isn't that surprising.<p>But Python is truly general purpose while the core query stuff in SQL is really specialized (we were not using stored procedures). So if Pypy can get 5x speedup, it seems to me that it should be possible to get the same kind of speed up in Postgres. I guess it needs funding and someone as smart as the Pypy people.
At some level the application needs to participate in the performance conversation too.<p><a href="https://www.postgresql.org/docs/current/sql-prepare.html" rel="nofollow">https://www.postgresql.org/docs/current/sql-prepare.html</a>
Postgres’s PREPARE is per-connection so it’s pretty limited, and then connection poolers enter the fray and often can’t track SQL-level prepares.<p>And then the issue is not dissimilar to Postgres’s planner issues.
Unless you cache query plans like other RDBMS's then the client manually managing that goes away and its not limited to a single connection.<p>MS SQL still has prepared statements and they really haven't been used in 20 years since it gained the ability to cache plans based on statement text.
What sort of things are people doing in their SQL queries that make them CPU bound? Admittedly I'm a meat-and-potatoes guy, but I like mine I/O bound.<p>Really amazed to see not one but several generic JIT frameworks though, no idea that was a thing.
Anything jsonb in my experience is quickly CPU bound...
I think reading queries that are always served from cache are CPU bound because it also involves locking the buffers etc and there is no I/O involved.
PostgreSQL is Turing complete, so I guess they do what ever they want?
The last time I looked into it my impression was that disabling the JIT in PostgreSQL was the better default choice. I had a massive slowdown in some queries, and that doesn't seem to be an entirely unusual experience. It does not seem worth it to me to add such a large variability to query performance by default. The JIT seemed like something that could be useful if you benchmark the effect on your actual queries, but not as a default for everyone.
That is quite strange, given that big boys RDMS (Oracle, SQL Server, DB2, Informix,...) all have JIT capabilities for several decades now.
Have you tested this under high concurrency with lots of short OLTP queries? I’m curious whether the much faster compile time actually moves the point where JIT starts paying off, or if it’s still mostly useful for heavier queries.
> By default, jit_above_cost parameter is set to a very high number (100'000). This makes sense for LLVM, but doesn't make sense for faster providers. It's recommended to set this parameter value to something from ~200 to low thousands for pg_jitter (depending on what specific backend you use and your specific workloads).
sadly, no windows version yet AFAICT
awesome! I wonder if it's possible to point AI at this problem and synthesize a bespoke compiler (per-architecture?) for postgresql expressions?
Two things are holding back current LLM-style AI of being of value here:<p>* Latency. LLM responses are measured in order of 1000s of milliseconds, where this project targets 10s of milliseconds, that's off by almost two orders of magnitute.<p>* Determinism. LLMs are inherently non-deterministic. Even with temperature=0, slight variations of the input lead to major changes in output. You really don't want your DB to be non-deterministic, ever.
> LLMs are inherently non-deterministic.<p>This isn't true, and certainly not inherently so.<p>Changes to input leading to changes in output does not violate determinism.
> This isn't true<p>From what I understand, in practice it often <i>is</i> true[1]:<p><i>Matrix multiplication should be “independent” along every element in the batch — neither the other elements in the batch nor how large the batch is should affect the computation results of a specific element in the batch. However, as we can observe empirically, this isn’t true.</i><p><i>In other words, the primary reason nearly all LLM inference endpoints are nondeterministic is that the load (and thus batch-size) nondeterministically varies! This nondeterminism is not unique to GPUs — LLM inference endpoints served from CPUs or TPUs will also have this source of nondeterminism.</i><p>[1]: <a href="https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/" rel="nofollow">https://thinkingmachines.ai/blog/defeating-nondeterminism-in...</a>
Quoting:<p>"But why aren’t LLM inference engines deterministic? One common hypothesis is that some combination of floating-point non-associativity and concurrent execution leads to nondeterminism based on which concurrent core finishes first."<p>From <a href="https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/" rel="nofollow">https://thinkingmachines.ai/blog/defeating-nondeterminism-in...</a>
> 1000s of milliseconds<p>Better known as "seconds"...
The suggestion was not to use an LLM to compile the expression, but to use an LLM to build the compiler.