At 22 years old, Postgres might just be the most advanced database yet

Re:At 22 years old, Postgres might just be the most advanced... by snuxoll on Wednesday December 05, 2018 @02:08PM (#18611386)

> Postgress makes a copy of _every_ row and you need 100GB of extra space on the hard-drive until you commit the transaction.

This only happens if the column is indexed, heap-only-tuples will allow in-place updates otherwise. This doesn't dismiss it as a potential problem entirely, but depending on your needs you may never run into this.

[ Parent | on HN ]

Re:At 22 years old, Postgres might just be the most advanced... by djd20 on Wednesday December 05, 2018 @02:17PM (#18611467)

I would argue thats an issue with your architecture at that point - you may want to use table partitioning at sizes that big, or have some other mechanism in place to be able to lock access while updating such large data sets in one go.

[ Parent | on HN ]

Re:At 22 years old, Postgres might just be the most advanced... by snuxoll on Wednesday December 05, 2018 @02:22PM (#18611529)

I would generally agree, though there are unfortunately limitations imposed on you the moment you start using partitioning with PostgreSQL (foreign keys remain to be a big one).

[ Parent | on HN ]

Re:At 22 years old, Postgres might just be the most advanced... by Tostino on Wednesday December 05, 2018 @10:17PM (#18615063)

Not as of PG 11

[ Parent | on HN ]

Re:At 22 years old, Postgres might just be the most advanced... by snuxoll on Thursday December 06, 2018 @02:15AM (#18616054)

You still can’t make FK references TO partitioned tables, unfortunately.

[ Parent | on HN ]

Re:At 22 years old, Postgres might just be the most advanced... by nly on Wednesday December 05, 2018 @02:51PM (#18611800)

So what's the workaround? Drop the index, update, then re-establish the index?

[ Parent | on HN ]