This bit about ICU support v.s. glibc:<p><pre><code> > [...] Furthermore, at least on Red Hat, glibc regularly whacks
> around the behavior of OS-native collations in minor releases,
> which effectively corrupts PostgreSQL's indexes, since the index
> order might no longer match the (revised) collation order. To
> me, changing the behavior of a widely-used system call in a
> maintenance release seems about as friendly as locking a family
> of angry racoons in someone's car, but the glibc maintainers
> evidently don't agree.
</code></pre>
Is a reference to the PostgreSQL devs wanting to make their index
order a function of strxfrm() calls and to not have it change when
glibc updates, whereas some on the glibc list think it should only be
used for feeding it to the likes of strcmp() in the same process:<p><pre><code> > The only thing that matters about strxfrm output is its strcmp
> ordering. If that changes, it's either a bug fix or a bug
> (either in the code or in the locale data). If the string
> contents change but the ordering doesn't, then it's an
> implementation detail that is allowed to change.
</code></pre>
-- <a href="https://sourceware.org/ml/libc-alpha/2015-09/msg00197.html" rel="nofollow">https://sourceware.org/ml/libc-alpha/2015-09/msg00197.html</a>
Ok, I'm not a database manager for enormous projects, so these changes may be great, but I don't understand them and don't care about them. Postgres is already the most awesome thing in Earth to me.<p>Still, if my opinion counts I think SELF-UPDATING MATERIALIZED VIEWS should be the next priority.
I deeply appreciate the great care that Postgres committers take in writing their merge messages.<p>I think of it as a sign of respect for future developers to take the time to write a clear account of what has happened.
I'm so excited for table partitioning. I use table inheritance in several places in my current project, but have felt the pain of foreign key constraints not applying to inherited children. Reading about table partitioning, I'm realizing that this is a much better fit for my use case.<p>Postgres continues to amaze me with the speed at which they introduce the right features into such a heavily-used and production-critical product. Thanks Postgres team!
Will DDL replication for the logical replication be landing in 10 or later?<p>We have some use cases where logical replication would be very helpful, but keeping the schema in sync manually seems like a pain - will there be a documented workaround if DDL replication doesn't make it in?
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. <a href="https://eng.uber.com/mysql-migration/" rel="nofollow">https://eng.uber.com/mysql-migration/</a> I had heard talk on Software Engineering Daily that this new major revision was supposed to address that.<p>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?
Can anyone recommend a decently up to date book on postgres administration? Or are docs really the only way? I've used SQL Server for years but would likely choose postgres for an independent project if I intended to commercialize it. That said, I don't use it at work so it's hard to get in depth experience.
Extended Statistics! I was following the replication changes, but have just discovered the extended statistics and am more excited about them.<p>The directory renaming at the bottom of the post is interesting - I wonder if many other projects have to do things like this?
The feature I'd really love is master selection with Raft or similar and automatic query redirection to the master for all write queries (and maybe for reads with a query keyword).<p>That would make it very easy and robust to cluster pg without requiring a big complicated (a.k.a. high admin overhead and failure prone) stack with lots of secondary tools.<p>This kind of fire and forget cluster is really the killer feature of things like MongoDB and RethinkDB. Yes people with really huge deployments might want something more tunable, but that's only like 1% of the market.<p>Of course those NoSQL databases also offer eventual and other weaker but more scalable consistency modes, but like highly tuned manual deployment these too are features for the 1% of the market that actually needs that kind of scale.<p>A fire and forget cluster-able fully consistent SQL database would be nirvana for most of the market.
Dumb question: does declarative partitioning pave the way for native sharding in Postgres? I'm not super super familiar, but it <i>seems</i> like along with some other features coming in Postgres 10, like parallel queries and logical replication, that this is eventually the goal.
Wow, so awesome.
I do hope at some point we can see some language improvements to PLPGSQL. More basic data structures could go a long way in making that language really useful, and I still consider views/stored procedures a superior paradigm to client side sql logic
What's the ops experience for a replicated setup like these days? i.e. assuming you want basic fault-tolerance at non-exotic size / activity levels, how much of a job is someone acquiring if, say, there are reasons they can't just use AWS RDS?
For analytical loads the following is going to be great:<p><pre><code> 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.</code></pre>
I am considering more and more a move back from MongoDB to PostgreSQL. I will be missing being schema less so much though. Migrations - particularly Rails migrations - left a bad taste in my mouth. Anyone did the move recently and what are their feelings?
I know that several RDF data stores use PostgreSQL as a backend data store. With new features like better XML support, as well as older features for storing hierarchical data, I am wishing for a plugin or extension for handling RDF with limited (not RDFS or OWL) SPARQL query support. I almost always have PostgreSQL available, and for RDF applications it would be very nice to not have to run a separate service.<p>I tend to view PostgreSQL as a "Swiss Army knife" and having native RDF support would reinforce that.
A question on this statement, in the SCRAM authentication description: <i>stealing the hashed password from the database or sniffing it on the wire is equivalent to stealing the password itself</i><p>How is that the case? That's exactly the thing that hashed passwords prevent. Of course, if it's just an MD5 hash that's feasibly vulnerable to brute-forcing today, but it's still not "equivalent" to having the clear-text password.
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!
fascinating that the road to improving the expr evaluator is better opcode dispatch and jit -- same tradeoffs every programming language project is looking at right now.