3 ms·

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

api 10y ago
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.
- mb4nck 10y ago
  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).
- xyzzy_plugh 10y ago
  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?
deleted 10y ago
[deleted]
manigandham 10y ago
> 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.
- xyzzy_plugh 10y ago
  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?
  - manigandham 10y ago
    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.

api 10y ago

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.

mb4nck 10y ago
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).
xyzzy_plugh 10y ago
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?

deleted 10y ago

[deleted]

manigandham 10y ago

> 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.

xyzzy_plugh 10y ago
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?
- manigandham 10y ago
  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.