11–20 of 138 posts
Dumb question: does declarative partitioning pave the way for native sharding in Postgres? I'm not super super familiar, but it seems like along with some other features coming in Postgres 10, like parallel queries and logical replication, that this is eventually the goal.
Dumb question: does declarative partitioning pave the way for native sharding in Postgres? I'm not super super familiar, but it seems like along with some other features coming in Postgres 10, like parallel queries and logical replication, that this is eventually the goal.
I hope that it will have that effect. We need a few other features first: partitionwise join, partitionwise aggregate, asynchronous query, and ideally hash partitioning.
Impressive feature list. Glad to see logical replication is finally making it in.
Extended Statistics! I was following the replication changes, but have just discovered the extended statistics and am more excited about them. The directory renaming at the bottom of the post is interesting - I wonder if many other projects have to do things like this?
The background is that, over the years, a number of people deleted the pg_xlog and pg_clog directories when they noticed they're running out of space, thinking it's just server logs. Unfortunately that's the directories containing the database journal, and transaction status (committed/aborted/in-progress). Which means they'll loose data. The idea is to rename them to something that's less likely to be mistaken for unimportant data.
Is this issue resolved by the new "Logical replication" feature? It doesn't seem directly related, but it seems like maybe that is what he is referring to in this blog post?
While PostgreSQL 9.6 offers parallel query, this feature
has been significantly improved in PostgreSQL 10, with new
features like Parallel Bitmap Heap Scan, Parallel Index
Scan, and others. Speedups of 2-4x are common with
parallel query, and these enhancements should allow those
speedups to happen for a wider variety of queries.I did read the article, but I can't find any mention of addressing the "Write amplification" issue as described by Uber when they moved away from postgres. https://eng.uber.com/mysql-migration/ I had heard talk on Software Engineering Daily that this new major revision was supposed to address that. Is this issue resolved by the new "Logical replication" feature? It doesn't seem directly related, but it seems like may…
Impressive feature list. Glad to see logical replication is finally making it in.
What is you use case for it? My only thought was sending just one table to replica to be used to do analytics on ..
This is great because I couldn't go to production with earlier releases of logical decoding. Now we don't have to depend on a third party add on!