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. eloisius · 1789612406 · focus · HN ↗

         What would you accelerate? Is there a lot of linear algebra you could throw cuda at in Postgres?

         1. dragontamer · 1789615564 · focus · HN ↗

            You know that GPUs are more flexible than just linear algebra, right?

            GPUs are simply faster at fundamental algorithms like sorting (which has huge parallelism), and hashing. This is because both sorting and hashing benefit from endless growth of parallelism, offering enough "work" for these 10,000 SIMD-core systems to crunch work upon.

            And because of modern algorithms/libraries with 'Mergepath sort' (a GPU-SIMD parallel sorting algorithm), its not even that difficult to implement anymore.

            Naturally, this then leads to parallel Sort Merge Join, as well as parallel Hash-Join (two ways to implement left or right joins in a GPU that benefit from significant parallelism).

            So yeah, Joins. <a href="https:&#x2F;&#x2F;www.kenchoi.dev&#x2F;papers&#x2F;gpu-joins.pdf" rel="nofollow">https:&#x2F;&#x2F;www.kenchoi.dev&#x2F;papers&#x2F;gpu-joins.pdf (This paper also has a description of &quot;Mergepath sort&quot;, a GPU parallel way of sorting)

            ---------

            Even if GPUs weren&#x27;t fundamentally faster at these kinds of operations... the RAM is simply 10x higher bandwidth and we all know its a RAM-constrained problem.

            Your typical SQL query is going to need multiple joins, probably a sort and possibly some &quot;group&quot; operations. As long as you have more than 10,000 elements or so (IE: can saturate all 10,000+ SIMD-units of a GPU), you&#x27;ll be able to at least benefit from the faster RAM.

            If you have a LOT of joins (a recursive join or some other kind of deeply nested computationally complex query), you probably benefit even more from the greater compute-power offered by GPUs. These operations (joins really) are nominally over the entire set of data, and cleanly break down into obvious parallelism.

            1. withinboredom · 1789626133 · focus · HN ↗

               The GPU isn’t connected to the disk though. Usually. So you’d still have to load from disk, to ram, then from ram to the GPU.

               1. yfontana · 1789634546 · focus · HN ↗

                  [dead]

               2. __alexs · 1789635157 · focus · HN ↗

                  PCI-E is really very flexible <a href="https:&#x2F;&#x2F;developer.nvidia.com&#x2F;gpudirect" rel="nofollow">https:&#x2F;&#x2F;developer.nvidia.com&#x2F;gpudirect
               3. swiftcoder · 1789655447 · focus · HN ↗

                  &gt; The GPU isn’t connected to the disk though. Usually.

                  It can be. That was the big new innovation in video game load times

Unofficial Hacker News client; not affiliated with Y Combinator.