Thread

1. refibrillator · 1789592742 · focus · HN ↗

   “81% faster query plans than Postgres”…on an 8 GB dataset that fits entirely in memory, with shared_buffers constrained to a fraction of that, queries warmed before measuring, and read-only SELECTs.

   I would be cautious about over fitting, it’s tough to say if those query plans would really be more optimal than Postgres heuristics at scale and with a bit more realistic OLTP workloads.

   In any case, such is life with profile guided optimization. Many of us appreciate how database workloads can drift over time and with scale.

   Kudos to the author for getting their hands dirty and writing up their experiments.

   1. dragontamer · 1789597400 · focus · HN ↗

      With a 4B parameter model that probably ran through 8GBs of RAM multiple times to run.

      At a certain point we should seriously talk about CUDA accelerating Postgres instead.

      1. bt1a · 1789601306 · focus · HN ↗

         pardon but aren't disks usually the bottleneck? im all for CUDA acceleration and CUDA accelerating culture

         1. voganmother42 · 1789603700 · focus · HN ↗

            I remember projects like PG-Strom back in the day, very cool stuff

Unofficial Hacker News client; not affiliated with Y Combinator.