My favorite abuse of prime numbers is to solve interview questions that ask you to detect whether two strings are palindromes: Assign a prime to each letter of the alphabet the strings are made out of and multiply. If the numbers you get are the same, the strings are palindromes.

This is just a fun approach. As another comment mentions, use INTEGER[]. Having to do factorization for every comment whose parents you want to display is perhaps not expensive, but definitely not free.

I don’t think it is better than a prefix tree. Using prime numbers is kind of funny and original, but I’ve never used this approach in a real product and I normally wouldn’t!

My favorite abuse of prime numbers is to solve interview questions that ask you to detect whether two strings are palindromes: Assign a prime to each letter of the alphabet the strings are made out of and multiply. If the numbers you get are the same, the strings are palindromes.

Do you mean anagrams? :p

Oh I do! orz

If numeric type in PostgreSQL can go up to 16383 digits after the decimal point, how many comments can I store this way?

If we’re taking Postgres, might as well have

`parents INTEGER[]`

and save yourself a lot of messing about.Or just use a recursive CTE

Interesting approach, but I’m curious about in which ways this is better than a prefix tree?

This is just a fun approach. As another comment mentions, use

`INTEGER[]`

. Having to do factorization for every comment whose parents you want to display is perhaps not expensive, but definitely not free.Recursive CTE is the solution in this case. Solves both “would need N joins” and “can’t count(*) comfortably”.

I don’t think it is better than a prefix tree. Using prime numbers is kind of funny and original, but I’ve never used this approach in a real product and I normally wouldn’t!

Ah, okay. Sorry for being confused :o