Features I'd Like in PostgreSQL

Re:Features I'd Like in PostgreSQL by bastawhiz on Sunday January 29, 2023 @02:13PM (#34571577)

> Also, you’ll still eventually need to go clean up the entire sequence

If you're using a numeric type, you get up to 16383 digits after the decimal. That's... Probably more precision than you'll be able to reasonably use up in almost any use case. Any time you're reordering in bulk, you're resetting the order value to a nice integer, so it would take many thousands of ad-hoc reordering operations near a single position to get it close to the precision limit, yeah?

https://www.postgresql.org/docs/current/datatype-numeric.htm...

[ Parent | on HN ]

Re:Features I'd Like in PostgreSQL by tshaddox on Sunday January 29, 2023 @03:30PM (#34572381)

Sure, but if it’s orders of magnitude more than you’ll ever need, you’re just using way more storage than you need. That’s what I meant by being more explicit about your plan and using more predictable storage. As a basic example, you could also use integer (or bigint) and start by number things like 1000, 2000, 3000, etc. Now you know exactly how many slots between items you have, and can more easily query for cases where you’re running low on slots.

[ Parent | on HN ]

Re:Features I'd Like in PostgreSQL by bastawhiz on Monday January 30, 2023 @10:37AM (#34581049)

Capacity doesn't mean storage. The default text field can store orders of magnitude more than I might need for a field, but that doesn't mean it takes orders of magnitude more storage.

[ Parent | on HN ]