Live data from Hacker News

Unconventional PostgreSQL Optimizations

hakibenita.com

71–72 of 72 posts

Re: Unconventional PostgreSQL Optimizations

#71
post #7

Great article, shows a lot of interesting PostgreSQL features. I have used PostgreSQL and MySQL for decades, and this article showed me that I have barely scratched the surface of what is possible.

PostgreSQL is like Emacs. It's an operating system disguised as something else.

I've heard Postgres described as a "database framework".

Re: Unconventional PostgreSQL Optimizations

#72
post #29

The hash technique for uniqueness isn’t supported for indexes because it doesn’t handle hash collisions. The authors proposed solution suffers the same problem- values which do not already exist in the table will sometimes be rejected because they have the same hash as something that was already saved.

This is completely untrue. While the index only stores the hashes, the table itself stores the full value and postgres requires both the hash and the full value to match before rejecting the new row. Ie. Duplicate hashes are fine.

For a unique index, that requires a table check, which - IIRC - isn’t implemented during index updates.

The article suggests using a check constraint to get around that - are you saying that does actually check the underlying value when USING HASH is set? If so, I think the docs need updating.

Post reply on HN