Re: [PERFORM] Need help in performance tuning.
Jesper Krogh wrote: I dont think a build-in connection-poller (or similiar) would in any way limit the actions and abillities of an external one? Two problems to recognize. First is that building something in has the potential to significantly limit use and therefore advancement of work on external pools, because of the "let's use the built in one instead of installing something extra" mentality. I'd rather have a great external project (which is what we have with pgBouncer) than a mediocre built-in one that becomes the preferred way just by nature of being in the core. If work on a core pooler was started right now, it would be years before that reached feature/performance parity, and during that time its existence would be a net loss compared to the current status quo for many who used it. The second problem is the limited amount of resources to work on improvements to PostgreSQL. If you want to improve the reach of PostgreSQL, I consider projects like materialized views and easy built-in partitioning to be orders of magnitude more useful things to work on than the marginal benefit of merging the features of the external pool software inside the database. I consider the whole topic a bit of a distraction compared to instead working on *any* of the highly rated ideas at http://postgresql.uservoice.com/forums/21853-general As a random technical note, I would recommend that anyone who is thinking about a pooler in core take a look at how pgBouncer uses libevent to respond to requests, a design model inspired by that of memcached. I haven't looked at it deeply yet, but my gut guess is that this proven successful model would be hard to graft on top of the existing PostgreSQL process design, and doing anything but that is unlikely to perform as well. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.us -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Pooling in Core WAS: Need help in performance tuning.
Right, let's not confuse Kevin's argument that we should have connection pooling in core with advocacy for any particular patch or feature suggestion that he may have offered on some other thread. A very simple in-core connection pooler might look something like this: when a session terminates, the backend doesn't exit. Instead, it waits for the postmaster to reassign it to a new connection, which the postmaster does in preference to starting new backends when possible. But if a backend doesn't get assigned a new connection within a certain period of time, then it goes ahead and exits anyway. This would, in my opinion, be an excellent option for PostgreSQL and would save a LOT of newbie pain. Going back to my list, it would help with both problems (a) and (c). It wouldn't be as good as pgbouncer, but it would be "good enough" for a lot of users. HOWEVER, there is the issue that such a mechanism isn't "free". There are issue with sharing backends around GUCs, user configuration, security, and prepared plans -- all issues which presently cause people difficulty with pgbouncer. I think the costs are worth it, but we'd have to make some attempt to tackle those issues as well. And, of course, we'd need to let DBAs turn the pooling off. I'd envision parameters: pool_connections true/false pool_connection_timeout 60s I'm also relying on the unsubstantiated assumption that it's possible to pass a socket connection between processes. Doesn't pgpool do this? Still another approach is admission control based on transactions, backends, queries, memory usage, I/O, or what have you. That's a different problem, and on its own doesn't help newbies. It's complimetary to pooling, though, so would be nice to have. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Pooling in Core WAS: Need help in performance tuning.
Josh Berkus writes: >> I'm also relying on the unsubstantiated assumption that it's >> possible to pass a socket connection between processes. > Doesn't pgpool do this? No, and in fact that's exactly why the proposed implementation isn't ever going to be in core: it's not possible to do it portably. (And no, I'm not interested in hearing about how you can do it on platforms X, Y, and/or Z.) I agree with the comments to the effect that this is really a packaging and documentation problem. There is no need for us to re-invent the existing solutions, but there is a need for making sure that they are readily available and people know when to use them. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
