Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Features Coming in PostgreSQL 10

rhaas.blogspot.com

Post reply on HN
Print view View original

131–138 of 138 posts

Re: New Features Coming in PostgreSQL 10

#131

Post by mb4nck »

api wrote: post #114
xyzzy_plugh wrote: post #99

Earlier quoted context omitted.

Can't pgbouncer/pgpool2 solve query redirection? I don't understand the desire for all-in-one solutions.

That desire comes from three places: 1. Minimize cognitive load by minimizing the number of things you have to learn. 2. Minimize deployment complexity and dependencies. 3. Complexity is just evil I'm general. Linear increases in complexity result in exponential increases in bugs, vulnerabilities, and failure modes. It's just combinatorics.

patroni builds upon etcd and (optionally) haproxy, two rather mature pieces of infrastructure (which can both be made HA on their own if SPOFs are to be avoided).

I understand where you are coming from, but having this kind of multi-server-who-is-master knowledge baked into Postgres itself will surely take another couple of releases, if it will be included at all.

Probably BDR (bi-directional replication, master-master like logical replication) will be there first, but whether the question is whether it will help a lot for local scale-out workloads (as opposed to glueing two datacenters together and allow transactions on both sides).

Re: New Features Coming in PostgreSQL 10

#132

Post by xyzzy_plugh »

MBCook wrote: post #109
xyzzy_plugh wrote: post #98

Earlier quoted context omitted.

If you steal the hash from the database, yes. I don't know how stealing the hash over-the-wire is equivalent to having the password, since it is salted (with a salt generated by the server) and is not reusable.

Because the next time you connect to the server you provide the same hash. The person doesn't know your plane text, but they can get into the server just fine.

You can't provide the same salted wire hash. You'd need the pre-salted hash, which only the client and server now. I fail to see how this answers my question.

Re: New Features Coming in PostgreSQL 10

#133

Post by xyzzy_plugh »

manigandham wrote: post #128
xyzzy_plugh wrote: post #99

Earlier quoted context omitted.

Can't pgbouncer/pgpool2 solve query redirection? I don't understand the desire for all-in-one solutions.

> I don't understand the desire for all-in-one solutions You really don't understand it? It's less moving pieces to think about, worry about, read about, deploy, maintain, fix and almost always leads to better performance and security. Something as simple as connection pooling should've already been part of the database and query redirection is even more important to have included.

Is it actually less moving pieces? The sum seems about the same. Your statement seems like FUD.

The unix philosophy of focusing on a single problem and solving it well seems to do just fine. I don't see why baking in featuress that the vast majority of users will never need is a good investment. If anything, it seems like it will only increase the complexity of postgresql. The protocol is well documented and open. Libpq provides all the functionality necessary. Why not bake the higher order logic into a discrete component?

Re: New Features Coming in PostgreSQL 10

#134

Post by xyzzy_plugh »

api wrote: post #114
xyzzy_plugh wrote: post #99

Earlier quoted context omitted.

Can't pgbouncer/pgpool2 solve query redirection? I don't understand the desire for all-in-one solutions.

That desire comes from three places: 1. Minimize cognitive load by minimizing the number of things you have to learn. 2. Minimize deployment complexity and dependencies. 3. Complexity is just evil I'm general. Linear increases in complexity result in exponential increases in bugs, vulnerabilities, and failure modes. It's just combinatorics.

Number 2 is the only point I see merit in. With respect to 3, isn't that an argument against increasing the complexity of postgresql?

Re: New Features Coming in PostgreSQL 10

#135

Post by jerven »

kuschku wrote: post #69
frik wrote: post #37

Earlier quoted context omitted.

Which RDF data store uses Postgres as DB backend? And can one import WikiData? (does it scale) (I would rather avoid these old school RDF special case stores from SematicWeb days 10 years ago.)

https://github.com/cayleygraph/cayley is currently on the frontpage of HN, and it does use PGSQL as backend.

Does it scale is a very valid question for Cayley. Running sparql.uniprot.org I know virtuoso scales easily to 27 billion triples. Best benchmark I have seen for Cayley is 21 million RDF triples.

RDF and relational are similar but free form RDF is hard to put into a pure relational schema, as schema is derived from the data in RDF. There are ways to recover relational schema's from RDF but these are not yet in production state.

Re: New Features Coming in PostgreSQL 10

#136

Post by manigandham »

xyzzy_plugh wrote: post #133
manigandham wrote: post #128

Earlier quoted context omitted.

> I don't understand the desire for all-in-one solutions You really don't understand it? It's less moving pieces to think about, worry about, read about, deploy, maintain, fix and almost always leads to better performance and security. Something as simple as connection pooling should've already been part of the database and query redirection is even more important to have included.

Is it actually less moving pieces? The sum seems about the same. Your statement seems like FUD. The unix philosophy of focusing on a single problem and solving it well seems to do just fine. I don't see why baking in featuress that the vast majority of users will never need is a good investment. If anything, it seems like it will only increase the complexity of postgresql. The protocol is well documented and open. Li…

That philosophy is just that - a philosophy that sounds nice and applies sometimes. It's not a rule.

The deployment and upkeep of components is a major hassle and yes, having it all bundled into the same running application (which is the only thing it can be used with anyway) decreases the amount of stuff the end-user has to worry about.

Scaling connections reasonably is something basic any database should handle natively - or better put hitting connection limits without yet another program to help is rather silly in 2017.

You can make the same argument about replication but half this thread is about logical replication being moved to core so we can get scalable distributed clusters in the future - something even fewers users would use but clearly has many benefits by being included in the main release.

Re: New Features Coming in PostgreSQL 10

#137

Post by osi »

jerven wrote: post #135
kuschku wrote: post #69

Earlier quoted context omitted.

https://github.com/cayleygraph/cayley is currently on the frontpage of HN, and it does use PGSQL as backend.

Does it scale is a very valid question for Cayley. Running sparql.uniprot.org I know virtuoso scales easily to 27 billion triples. Best benchmark I have seen for Cayley is 21 million RDF triples. RDF and relational are similar but free form RDF is hard to put into a pure relational schema, as schema is derived from the data in RDF. There are ways to recover relational schema's from RDF but these are not yet in produc…

i helped build a triple store on top of postgresql back in '06-'08. company is gone so i don't know where the IP ended up, but it was a good foundation. we were competitive with the other players at the time.

Re: New Features Coming in PostgreSQL 10

#138

Post by scurvy »

mb4nck wrote: post #129
scurvy wrote: post #125

Earlier quoted context omitted.

I had not. Looks like it requires 9.5 or later? We're running 9.4 so we'll have to upgrade to use it. Thanks!

You can get pg_rewind for 9.4 (and 9.3 in its branch) here: https://github.com/vmware/pg_rewind/tree/REL9_4_STABLE It's from the people who wrote it upstream, they provide the code there for earlier Postgres releases.

Does this help at all with upgrades? Upgrading from 9.4 to 9.5 means you need to rebuild your entire replication topology because the master's identifier has changed (in the initdb step of the official docs).
Post reply on HN