> bidirectional logical replication
Just to make sure, this is what we used to call multi-master, right?
(This is not a "why did they change it" post. Do not make it into a "why did they change it" post.)
PostgreSQL 16
41–50 of 89 posts
Re: PostgreSQL 16
#42> bidirectional logical replication Just to make sure, this is what we used to call multi-master, right? (This is not a "why did they change it" post. Do not make it into a "why did they change it" post.)
Yes
Re: PostgreSQL 16
#43I am so glad psql got \bind.
What good does EXPLAIN do if you're not running the same (parameterized) queries that your app does? Very cool.
Re: PostgreSQL 16
#44Earlier quoted context omitted.
I’m not familiar with the VACUUM changes but the situation you’re describing suggests something is wrong with the table definition or database configuration.
How do you figure? Postgres docs are quite clear. Table space is not reclaimed without a vacuum full. So delete a column in a big table? you are storing that data forever.
Not quite true. Regular VACUUM marks dead tuples as available for re-use, so the system can overwrite the dead tuples with fresh ones after a VACUUM. VACUUM FULL completely rewrites and repacks the table.
Re: PostgreSQL 16
#45Earlier quoted context omitted.
I’m not familiar with the VACUUM changes but the situation you’re describing suggests something is wrong with the table definition or database configuration.
How do you figure? Postgres docs are quite clear. Table space is not reclaimed without a vacuum full. So delete a column in a big table? you are storing that data forever.
...okay ? What's the use case where data shrinks ?
The data that will be "not removed" will just be used by new data.
Only real use case is "we've loaded way too many data, removed it, and want to recover that space because we will never need it", and that is not enough to matter, as usually database have its own filesystem and most filesystems can't be shrunk online so any shrinking needs downtime
Re: PostgreSQL 16
#46anytime a huge multi-decades-old FOSS project lands a milestone, I can't help but equate it to something like a moon landing. So much (unpaid) work and thought goes into stewarding open software. Kudos to the whole team. Software infra is just as important as bridges and roads -- here's hoping we can fund it at least as well, for humanity's sake. [1] [1]: https://www.fordfoundation.org/work/learning/research-report..…
16 contains paid work
Re: PostgreSQL 16
#47anytime a huge multi-decades-old FOSS project lands a milestone, I can't help but equate it to something like a moon landing. So much (unpaid) work and thought goes into stewarding open software. Kudos to the whole team. Software infra is just as important as bridges and roads -- here's hoping we can fund it at least as well, for humanity's sake. [1] [1]: https://www.fordfoundation.org/work/learning/research-report..…
Agreed - just think about the billions, possibly trillions of economic value (jobs, shareholder value, utility to society, etc) that a project like postgres or ruby on rails has created.
Re: PostgreSQL 16
#48> bidirectional logical replication Just to make sure, this is what we used to call multi-master, right? (This is not a "why did they change it" post. Do not make it into a "why did they change it" post.)
https://www.crunchydata.com/blog/active-active-postgres-16 may interest you, also, which showed up recently https://news.ycombinator.com/item?id=37510260
Re: PostgreSQL 16
#49I can't wait for direct I/O (now behind debug_io_direct setting).
Re: PostgreSQL 16
#50Earlier quoted context omitted.
How do you figure? Postgres docs are quite clear. Table space is not reclaimed without a vacuum full. So delete a column in a big table? you are storing that data forever.
...okay ? What's the use case where data shrinks ? The data that will be "not removed" will just be used by new data. Only real use case is "we've loaded way too many data, removed it, and want to recover that space because we will never need it", and that is not enough to matter, as usually database have its own filesystem and most filesystems can't be shrunk online so any shrinking needs downtime
> What's the use case where data shrinks ?
Parent literally provided one: deleting a column.
Another is that it's very easy in PostgreSQL to bloat indexes. Load a bunch of data. Update (or delete) that data and now your index is bloated.
The only resolution is to REINDEX (or VACUUM FULL).