Optimizing Datalog for the GPU · HackerPapers discussions

Optimizing Datalog for the GPU — mentioned by lmeyerov

Sun, 26 Apr 2026 02:49:49 GMT

arxiv: https://arxiv.org/html/2311.02206v5 I've been a fan of this series! The work by this team, as well as kuzudb (acquired by apple) and relational.ai, have similar vibes. One area that has been especially interesting to me is identifying cases where new kinds of vector-friendly join operators are helpful . We've been doing a very different kind of oss gpu graph query language & engine (gfql), where we're solving how to turn declarative cypher property graph queries on big parquets / sql db results / etc -> query plans over scalable cpu/gpu dataframe operations that trounce neo4j etc at a…

Paper and discussion history. A mention is not an endorsement.

Optimizing Datalog for the GPU — mentioned by winwang

Sat, 09 Nov 2024 20:00:23 GMT

Until I get around to it, there's this blog post I wrote: https://wiwa.substack.com/p/can-we-10x-rust-hashmap-throughp... Not an "expert" on GPU hash tables, but I'm mildly aware of other hashmap things like a novel(?) hash-indexed sorted array (HISA): https://arxiv.org/html/2311.02206v3

Paper and discussion history. A mention is not an endorsement.

Optimizing Datalog for the GPU — mentioned by cmrdporcupine

Fri, 11 Oct 2024 14:09:14 GMT

So much of the "magic" with Prolog and similar relational languages necessarily happens with dynamic data at runtime (especially in a game engine where entities move around, etc so the state of relations changes significantly) I'm not sure how much static you could get with it. That said, there's plenty of research in the DB world on precompiled and JITted query execution plans. All of that would apply to a Prolog or Datalog engine as well. Also, a personal interest of mine I keep wanting to come back to is how much one can make use of GPU and TPU hardware to accelerate the joins that go on…

Paper and discussion history. A mention is not an endorsement.

Optimizing Datalog for the GPU — HN submission

Sun, 21 Jan 2024 22:46:11 GMT

Ask HN: Who's writing recursive queries / Datalog?

tl;dr: show me the most interesting recursive queries you've seen / written! "No practical applications of recursive query theory... have been found to date" - Michael Stonebraker, 1998 Readings in Database Systems, 3rd Edition Stonebraker and Hellerstein, eds. Datalog fans [1-3] love to use this quote from 20 years ago, then cite a bunch of applications of Datalog to prove Stonebraker wrong. Indeed, researchers came to love Datalog, and can’t seem to get enough of it in DB/PL conferences. Nevertheless, every new Datalog paper [4-7] still uses the same bunch of artificial queries pulled from…

8 points; 1 discussion reply on HN. Paper and source history. A submission is not an endorsement.

Optimizing Datalog for the GPU — mentioned by westurner

Sun, 03 Dec 2023 20:11:22 GMT

"GDlog: A GPU-Accelerated Deductive Engine" (2023) https://arxiv.org/abs/2311.02206 : > Abstract: Modern deductive database engines (e.g., LogicBlox and Soufflé) enable their users to write declarative queries which compute recursive deductions over extensional data, leaving their high-performance operationalization (query planning, semi-naïve evaluation, and parallelization) to the engine. Such engines form the backbone of modern high-throughput applications in static analysis, security auditing, social-media mining, and business analytics. State-of-the-art engines are built upon nested loop…

Paper and discussion history. A mention is not an endorsement.

Optimizing Datalog for the GPU — HN submission

Sun, 03 Dec 2023 18:08:23 GMT

GDlog: A GPU-accelerated deductive engine

127 points; 13 discussion replies on HN. Paper and source history. A submission is not an endorsement.

Optimizing Datalog for the GPU — HN submission

Thu, 30 Nov 2023 04:41:45 GMT

GDlog: A GPU-Accelerated Deductive Engine

3 points; 0 discussion replies on HN. Paper and source history. A submission is not an endorsement.