JoelJacobson

Joined 15 years ago

Karma
1,358
Submissions
376
Member since
Nov 30
View on Hacker News

Recent submissions

Comment · 2 months ago
In the article, the linked equivalent query is https://github.com/gregrahn/join-order-benchmark/blob/master... which is written using legacy comma-separated joins and a huge WHERE clause:

    SELECT MIN(an.name) AS cool_actor_pseudonym,
           MIN(t.title) AS series_named_after_char
    FROM aka_name AS an,
         cast_info AS ci,
         company_name AS cn,
         keyword AS k,
         movie_companies AS mc,
         movie_keyword AS mk,
         name AS n,
         title AS t
    WHERE cn.country_code ='[us]'
      AND k.keyword ='character-name-in-title'
      AND an.person_id = n.id
      AND n.id = ci.person_id
      AND ci.movie_id = t.id
      AND t.id = mk.movie_id
      AND mk.keyword_id = k.id
      AND t.id = mc.movie_id
      AND mc.company_id = cn.id
      AND an.person_id = ci.person_id
      AND ci.movie_id = mc.movie_id
      AND ci.movie_id = mk.movie_id
      AND mc.movie_id = mk.movie_id;
Cleaned up written as ON joins eliminating redundant quals:

    SELECT MIN(an.name) AS cool_actor_pseudonym,
           MIN(t.title) AS series_named_after_char
    FROM cast_info AS ci
    JOIN name            AS n  ON n.id         = ci.person_id
    JOIN title           AS t  ON t.id         = ci.movie_id
    JOIN aka_name        AS an ON an.person_id = n.id
    JOIN movie_keyword   AS mk ON mk.movie_id  = t.id
    JOIN keyword         AS k  ON k.id         = mk.keyword_id
    JOIN movie_companies AS mc ON mc.movie_id  = t.id
    JOIN company_name    AS cn ON cn.id        = mc.company_id
    WHERE cn.country_code = '[us]'
      AND k.keyword = 'character-name-in-title';
The keyword and company branches only control existence though; their row multiplicities cannot affect MIN. We can therefore optimize this using EXISTS:

   SELECT MIN(an.name) AS cool_actor_pseudonym,
          MIN(t.title) AS series_named_after_char
   FROM cast_info AS ci
   JOIN title AS t ON t.id = ci.movie_id
   JOIN aka_name AS an ON an.person_id = ci.person_id
   WHERE EXISTS
   (
       SELECT 1
       FROM movie_keyword AS mk
       JOIN keyword AS k ON k.id = mk.keyword_id
       WHERE mk.movie_id = t.id
         AND k.keyword = 'character-name-in-title'
   )
   AND EXISTS
   (
       SELECT 1
       FROM movie_companies AS mc
       JOIN company_name AS cn ON cn.id = mc.company_id
       WHERE mc.movie_id = t.id
         AND cn.country_code = '[us]'
   );
Shameless plug: We're working on a new proposed SQL feature to add explicit syntax for key joins: https://keyjoin.org Here is how the query could then be rewritten further:

    SELECT MIN(an.name) AS cool_actor_pseudonym,
           MIN(t.title) AS series_named_after_char
    FROM cast_info AS ci
    JOIN title AS t FOR KEY (id) <- ci (movie_id)
    JOIN aka_name AS an ON an.person_id = ci.person_id
    WHERE EXISTS
    (
        SELECT 1
        FROM movie_keyword AS mk
        JOIN keyword AS k FOR KEY (id) <- mk (keyword_id)
        WHERE mk.movie_id = t.id
          AND k.keyword = 'character-name-in-title'
    )
    AND EXISTS
    (
        SELECT 1
        FROM movie_companies AS mc
        JOIN company_name AS cn FOR KEY (id) <- mc (company_id)
        WHERE mc.movie_id = t.id
          AND cn.country_code = '[us]'
    );
Note: for this to work, I had to add referential constraints (aka "foreign keys") to the join-order-benchmark, which only had PRIMARY KEYs declared.
Comment · 2 months ago
I wonder what a nontrivial multi-table query with joins look like in Acadia?
Comment · 3 months ago
I'm not a native English speaker, I know "memory safe" has a precise technical meaning, but the word "safe" still feels a bit strange to me given that a memory-safety bug can make the program crash at run-time.

Sure, Fil-C prevents the bug from possibly being exploited, which is a huge improvement. But crashing can be a DoS attack, and if running a mission-critical system, it might not be an acceptable outcome.

I just feel the already very good presentation could have been made much better if it had put more weight on explaining these trade-offs.

Comment · 3 months ago
I was amazed by the presentation all the way up until 33:47, where the buggy program compiles and only errors out when the invalid access is executed. So apparently Fil-C enforces memory safety dynamically at run-time, rather than detecting these bugs at compile-time.

A new language designed around memory safety, such as Rust, can reject large and important classes of memory-safety bugs at compile-time. Rust does not catch everything at compile-time, like bounds checks and RefCell, which are checked at run-time(, and the problems due to unsafe and C interop like explained in the presentation.)

Still, IMO the comparison becomes a bit apples vs pears when bragging about how much more memory-safe Fil-C is than Rust. It would have been helpful to explain this important difference about run-time vs compile-time.

Very cool and useful anyway.

Comment · 3 months ago
Comment · 3 months ago
Comment · 3 months ago
Comment · 4 months ago
Comment · 4 months ago
Sorry, should have emphasized that it was the "much easier" part I didn't agree with in that interview.
Comment · 4 months ago
Comment · 4 months ago
I think we can't rule out the explanation that all the ideas of space data centers could be connected to a desire by some of finding additional applications for rockets that can transport stuff to space.
Comment · 5 months ago

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton