How bloom filters made SQLite 10x faster

Re:How bloom filters made SQLite 10x faster by leourbina on Monday December 23, 2024 @09:37AM (#42494669)

UUIDs are very wasteful [1]. For most use cases you can replace them with much shorter strings and still have very low chances of collisions [2]

[1] https://henvic.dev/posts/uuid/

[2] https://alex7kom.github.io/nano-nanoid-cc/

[ Parent | on HN ]

Re:How bloom filters made SQLite 10x faster by cogman10 on Monday December 23, 2024 @11:38AM (#42495656)

Call me crazy, but I'm simply splitting my UUID into the higher and lower bits and indexing off that.

    CREATE TABLE foo(
        id_ms    UNSIGNED BIG INT NOT NULL,
        id_ls    UNSIGNED BIG INT NOT NULL,
        PRIMARY KEY (id_ms, id_ls)
    ) WITHOUT ROWID;

That works well with UUIDv7 and is just storing 128bits rather than a full string. In most languages it's pretty trivial to turn 2 longs into a UUID and vice versa.

[ Parent | on HN ]

Re:How bloom filters made SQLite 10x faster by diroussel on Wednesday December 25, 2024 @07:50AM (#42508553)

Is there any advantage to this approach over Postgres native uuid support which should store the same number of bits?

[ Parent | on HN ]

Re:How bloom filters made SQLite 10x faster by cogman10 on Wednesday December 25, 2024 @07:11PM (#42512146)

No. This approach is strictly for DBS like sqlite without uuid or 128bit integer support.

[ Parent | on HN ]

Re:How bloom filters made SQLite 10x faster by PittleyDunkin on Monday December 23, 2024 @09:56AM (#42494812)

Sure, at cost of increased complexity of access. Sometimes the waste is worth the simplicity.

[ Parent | on HN ]

Re:How bloom filters made SQLite 10x faster by dymk on Monday December 23, 2024 @03:39PM (#42497408)

Sounds complex, just use a UUID. If that’s the dominating factor for storage, then you have a different problem to solve.

[ Parent | on HN ]