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. dragontamer · 1789605369 · focus · HN ↗

            Parent post was talking about an 8GB dataset.

            8GB isn't even CPU RAM these days. That's GPU super-mega-awesome ram. Ordinary Server CPUs are regularly pushing 2TB capacities.

            GPUs are in the 8GB to 32GB typically, at least for smaller and more regular GPUs. This GPU RAM is also well known to be at least 10x the bandwidth of CPU RAM.

            1. saghm · 1789619478 · focus · HN ↗

               Yeah, I have a GPU from almost six years ago in my desktop that has twice that much VRAM. Less than a year ago my wife got a 5070 Ti with the same for around $750 without needing to wait for it to be in stock or anything. I'm inclined to think that for a server that needs a GPU, even 32 GB would probably be considered small.

Unofficial Hacker News client; not affiliated with Y Combinator.