Live data from Hacker News

Partitioning Postgres tables by timestamp based UUIDs

elixirforum.com

11–12 of 12 posts

Re: Partitioning Postgres tables by timestamp based UUIDs

#11

Nice writeup, very helpful! I wonder at what point it makes more sense to adopt UUID v7 instead of ULID, but I guess that's a relatively irrelevant point.

I actually did a partitioned table over uuid v7. It works nicely, but the extension requieres manual installation which is sort of a pain.

Its coming as built-in function: https://commitfest.postgresql.org/43/4388/ hopefully it gets merged before the next release.

Re: Partitioning Postgres tables by timestamp based UUIDs

#12
post #3

> No matter what indexes we threw at the table I don't have information on how team investigated the whole problem. What table looks like? What indexes exactly? Was there any explain analyzing? 28 millions are not as many as it seems. We have similar sized table but when indexed properly, query is always quick

Also what I think. And it feels like partitioning would imply much more work and potential future implications rather than figuring out what was the issue with some queries or indexes. Postgres should be able to handle billions of rows. And if the issue was with the queries per second, it would feel to me like it would still be less disruptive to just have some sort of replication going on for reads. And partitioning…

A big benefit of partitioning is being able to drop partitions that expire instead of doing deletes. Assuming you’ll ever need to delete of course!
Post reply on HN