Re: Built-in connection pooling

New versions of built-in connection pool is attached to this mail. Now client's startup package is received by one of listener workers and postmater knows database/user name of the recevied connection and so is able to marshal it to the proper connection pool. Right now SSL is not supported.

Re: Built-in connection pooling

On Thu, May 17, 2018 at 9:09 PM, Bruce Momjian wrote: >> However, I think that's probably worrying about the wrong end of the >> problem first. IMHO, what we ought to start by doing is considering >> what a good architecture for this would be, and how to solve the >> general

Re: Built-in connection pooling

On Fri, May 4, 2018 at 03:25:15PM -0400, Robert Haas wrote: > On Fri, May 4, 2018 at 11:22 AM, Merlin Moncure wrote: > > If we are breaking 1:1 backend:session relationship, what controls > > would we have to manage resource consumption? > > I mean, if you have a large

Re: Built-in connection pooling

On 05.05.2018 00:54, Merlin Moncure wrote: On Fri, May 4, 2018 at 2:25 PM, Robert Haas wrote: On Fri, May 4, 2018 at 11:22 AM, Merlin Moncure wrote: If we are breaking 1:1 backend:session relationship, what controls would we have to manage

Re: Built-in connection pooling

On Fri, May 4, 2018 at 5:54 PM, Merlin Moncure wrote: >> I mean, if you have a large number of sessions open, it's going to >> take more memory in any design. If there are multiple sessions per >> backend, there may be some possibility to save memory by allocating it >>

Re: Built-in connection pooling

On 04.05.2018 18:22, Merlin Moncure wrote: On Thu, May 3, 2018 at 12:01 PM, Robert Haas wrote: On Fri, Apr 27, 2018 at 4:43 PM, Merlin Moncure wrote: What _I_ (maybe not others) want is a faster pgbouncer that is integrated into the database; IMO

Re: Built-in connection pooling

On Fri, May 4, 2018 at 2:25 PM, Robert Haas wrote: > On Fri, May 4, 2018 at 11:22 AM, Merlin Moncure wrote: >> If we are breaking 1:1 backend:session relationship, what controls >> would we have to manage resource consumption? > > I mean, if you have a

Re: Built-in connection pooling

On Fri, May 4, 2018 at 11:22 AM, Merlin Moncure wrote: > If we are breaking 1:1 backend:session relationship, what controls > would we have to manage resource consumption? I mean, if you have a large number of sessions open, it's going to take more memory in any design. If

Re: Built-in connection pooling

On Thu, May 3, 2018 at 12:01 PM, Robert Haas wrote: > On Fri, Apr 27, 2018 at 4:43 PM, Merlin Moncure wrote: >> What _I_ (maybe not others) want is a >> faster pgbouncer that is integrated into the database; IMO it does >> everything exactly right. > >

Re: Built-in connection pooling

On 03.05.2018 20:01, Robert Haas wrote: On Fri, Apr 27, 2018 at 4:43 PM, Merlin Moncure wrote: What _I_ (maybe not others) want is a faster pgbouncer that is integrated into the database; IMO it does everything exactly right. I have to admit that I find that an amazing

Re: Built-in connection pooling

On Fri, Apr 27, 2018 at 4:43 PM, Merlin Moncure wrote: > What _I_ (maybe not others) want is a > faster pgbouncer that is integrated into the database; IMO it does > everything exactly right. I have to admit that I find that an amazing statement. Not that pgbouncer is bad

Re: Built-in connection pooling

On 27.04.2018 23:43, Merlin Moncure wrote: On Fri, Apr 27, 2018 at 11:44 AM, Konstantin Knizhnik wrote: On 27.04.2018 18:33, Merlin Moncure wrote: On Fri, Apr 27, 2018 at 10:05 AM, Konstantin Knizhnik wrote: On 27.04.2018 16:49,

Re: Built-in connection pooling

On Fri, Apr 27, 2018 at 11:44 AM, Konstantin Knizhnik wrote: > > > On 27.04.2018 18:33, Merlin Moncure wrote: >> On Fri, Apr 27, 2018 at 10:05 AM, Konstantin Knizhnik >> wrote: >>> On 27.04.2018 16:49, Merlin Moncure wrote: >> I'm confused

Re: Built-in connection pooling

On 27.04.2018 18:33, Merlin Moncure wrote: On Fri, Apr 27, 2018 at 10:05 AM, Konstantin Knizhnik wrote: On 27.04.2018 16:49, Merlin Moncure wrote: *) How are you pinning client connections to an application managed transaction? (IMNSHO, this feature is useless

Re: Built-in connection pooling

On Fri, Apr 27, 2018 at 10:05 AM, Konstantin Knizhnik wrote: > On 27.04.2018 16:49, Merlin Moncure wrote: >> *) How are you pinning client connections to an application managed >> transaction? (IMNSHO, this feature is useless without being able to do >> that) > > Sorry,

Re: Built-in connection pooling

On 27.04.2018 16:49, Merlin Moncure wrote: On Thu, Apr 26, 2018 at 6:04 AM, Konstantin Knizhnik wrote: On 25.04.2018 20:02, Merlin Moncure wrote: Yep. The main workaround today is to disable them. Having said that, it's not that difficult to imagine hooking

Re: Built-in connection pooling

On Wed, Apr 25, 2018 at 10:09 PM, Michael Paquier wrote: > On Wed, Apr 25, 2018 at 03:42:31PM -0400, Robert Haas wrote: >> The difficulty of finding them all is really the problem. If we had a >> reliable way to list everything that needs to be moved into session >> state,

Re: Built-in connection pooling

On Thu, Apr 26, 2018 at 6:04 AM, Konstantin Knizhnik wrote: > On 25.04.2018 20:02, Merlin Moncure wrote: >> Yep. The main workaround today is to disable them. Having said that, >> it's not that difficult to imagine hooking prepared statement creation >> to a backend

Re: Built-in connection pooling

On 26.04.2018 05:09, Michael Paquier wrote: On Wed, Apr 25, 2018 at 03:42:31PM -0400, Robert Haas wrote: The difficulty of finding them all is really the problem. If we had a reliable way to list everything that needs to be moved into session state, then we could try to come up with a design

Re: Built-in connection pooling

On 25.04.2018 20:02, Merlin Moncure wrote: Would integrated pooling help the sharding case (genuinely curious)? I don't quite have my head around the issue. I've always wanted pgbouncer to be able to do things like round robin queries to non-sharded replica for simple load balancing but it

Re: Built-in connection pooling

On Wed, Apr 25, 2018 at 03:42:31PM -0400, Robert Haas wrote: > The difficulty of finding them all is really the problem. If we had a > reliable way to list everything that needs to be moved into session > state, then we could try to come up with a design to do that. > Otherwise, we're just

Re: Built-in connection pooling

On Wed, Apr 25, 2018 at 2:58 PM, Robert Haas wrote: > On Wed, Apr 25, 2018 at 10:00 AM, Merlin Moncure wrote: >> systems. If we get that tor free I'd be all for it but reading >> Robert's email I'm skeptical there are easy wins here. So +1 for >>

Re: Built-in connection pooling

On Wed, Apr 25, 2018 at 10:00 AM, Merlin Moncure wrote: > systems. If we get that tor free I'd be all for it but reading > Robert's email I'm skeptical there are easy wins here. So +1 for > further R and -1 for holding things up based on full > transparency...no harm in

Re: Built-in connection pooling

On Tue, Apr 24, 2018 at 1:00 PM, Konstantin Knizhnik wrote: > My expectation is that there are very few of them which has session-level > lifetime. > Unfortunately it is not so easy to locate all such places. Once such > variables are located, them can be saved in

Re: Built-in connection pooling

On Wed, Apr 25, 2018 at 9:43 AM, Christophe Pettus wrote: > >> On Apr 25, 2018, at 07:00, Merlin Moncure wrote: >> The limitations headaches that I suffer with pgbouncer project (which >> I love and use often) are mainly administrative and performance >>

Re: Built-in connection pooling

> On Apr 25, 2018, at 07:00, Merlin Moncure wrote: > The limitations headaches that I suffer with pgbouncer project (which > I love and use often) are mainly administrative and performance > related, not lack of session based server features. For me, the most common issue I

Re: Built-in connection pooling

On 25.04.2018 17:00, Merlin Moncure wrote: On Wed, Apr 25, 2018 at 12:34 AM, Christophe Pettus wrote: On Apr 24, 2018, at 06:52, Merlin Moncure wrote: Why does it have to be completely transparent? The main reason to move it into core is to avoid the

Re: Built-in connection pooling

On Wed, Apr 25, 2018 at 12:34 AM, Christophe Pettus wrote: > >> On Apr 24, 2018, at 06:52, Merlin Moncure wrote: >> Why does it have to be completely transparent? > > The main reason to move it into core is to avoid the limitations that a > non-core pooler

Re: Built-in connection pooling

> On Apr 24, 2018, at 06:52, Merlin Moncure wrote: > Why does it have to be completely transparent? Well, we have non-transparent connection pooling now, in the form of pgbouncer, and the huge fleet of existing application-stack poolers. The main reason to move it into

Re: Built-in connection pooling

On 23.04.2018 23:14, Robert Haas wrote: On Wed, Apr 18, 2018 at 9:41 AM, Heikki Linnakangas wrote: Well, may be I missed something, but i do not know how to efficiently support 1. Temporary tables 2. Prepared statements 3. Sessoin GUCs with any external connection pooler

Re: Built-in connection pooling

On Tue, Apr 24, 2018 at 9:52 AM, Merlin Moncure wrote: > > Why does it have to be completely transparent? As long as the feature > is optional (say, a .conf setting) the tradeoffs can be managed. It's > a reasonable to expect to exchange some functionality for pooling; >

Re: Built-in connection pooling

On Mon, Apr 23, 2018 at 3:14 PM, Robert Haas wrote: > In other words, transparent connection pooling is going to require > some new mechanism, which third-party code will have to know about, > for tracking every last bit of session state that might need to be > preserved or

Re: Built-in connection pooling

On 23.04.2018 21:56, Robert Haas wrote: On Fri, Jan 19, 2018 at 11:59 AM, Tomas Vondra wrote: Hmmm, that's unfortunate. I guess you'll have process the startup packet in the main process, before it gets forked. At least partially. I'm not keen on a design that

Re: Built-in connection pooling

On Mon, Apr 23, 2018 at 09:53:37PM -0400, Bruce Momjian wrote: > On Mon, Apr 23, 2018 at 09:47:07PM -0400, Robert Haas wrote: > > On Mon, Apr 23, 2018 at 7:59 PM, Bruce Momjian wrote: > > > So, instead of trying to multiplex multiple sessions in a single > > > operating system

Re: Built-in connection pooling

On Mon, Apr 23, 2018 at 09:47:07PM -0400, Robert Haas wrote: > On Mon, Apr 23, 2018 at 7:59 PM, Bruce Momjian wrote: > > So, instead of trying to multiplex multiple sessions in a single > > operating system process, why don't we try to reduce the overhead of > > idle sessions

Re: Built-in connection pooling

On Mon, Apr 23, 2018 at 7:59 PM, Bruce Momjian wrote: > So, instead of trying to multiplex multiple sessions in a single > operating system process, why don't we try to reduce the overhead of > idle sessions that each have an operating system process? We already > use procArray

Re: Built-in connection pooling

On Fri, Apr 20, 2018 at 11:40:59AM +0300, Konstantin Knizhnik wrote: > > Sorry, may we do not understand each other. > There are the following facts: > 1. There are some entities in Postgres which are local to a backend: > temporary tables, GUCs, prepared statement, relation and catalog

Re: Built-in connection pooling

On Fri, Jan 19, 2018 at 11:59 AM, Tomas Vondra wrote: > Hmmm, that's unfortunate. I guess you'll have process the startup packet > in the main process, before it gets forked. At least partially. I'm not keen on a design that would involve doing more stuff in the

Re: Built-in connection pooling

> 19 апр. 2018 г., в 23:59, Andres Freund написал(а): > > I think there's plenty things that don't really make sense solving > outside of postgres: > - additional added hop / context switches due to external pooler > - temporary tables > - prepared statements > - GUCs and

Re: Built-in connection pooling

>> I understand your customers like to have unlimited number of >> connections. But my customers do not. (btw, even with normal >> PostgreSQL, some of my customers are happily using over 1k, even 5k >> max_connections). > > If you have limited number of client, then you do not need pooling at >

Re: Built-in connection pooling

On Fri., 20 Apr. 2018, 06:59 Andres Freund, wrote: > On 2018-04-19 15:01:24 -0400, Tom Lane wrote: > > Only after you can say "there's nothing wrong with this that isn't > > directly connected to its not being in-core" does it make sense to try > > to push the logic into

Re: Built-in connection pooling

On 20.04.2018 12:02, Tatsuo Ishii wrote: I understand your customers like to have unlimited number of connections. But my customers do not. (btw, even with normal PostgreSQL, some of my customers are happily using over 1k, even 5k max_connections). If you have limited number of client,

Re: Built-in connection pooling

This is only applied to external process type pooler (like Pgpool-II). > - temporary tables > - prepared statements > - GUCs and other session state These are only applied to "non session based" pooler; sharing a database connection with multiple client connections.

Re: Built-in connection pooling

On 20.04.2018 11:16, Tatsuo Ishii wrote: On 20.04.2018 01:58, Tatsuo Ishii wrote: I think there's plenty things that don't really make sense solving outside of postgres: - additional added hop / context switches due to external pooler This is only applied to external process type pooler

Re: Built-in connection pooling

> On 20.04.2018 01:58, Tatsuo Ishii wrote: >>> I think there's plenty things that don't really make sense solving >>> outside of postgres: >>> - additional added hop / context switches due to external pooler >> This is only applied to external process type pooler (like Pgpool-II). >> >>> -

Re: Built-in connection pooling

On 20.04.2018 03:14, Tatsuo Ishii wrote: On Fri, Apr 20, 2018 at 07:58:00AM +0900, Tatsuo Ishii wrote: Yeah. Since SCRAM auth is implemented, some connection poolers including Pgpool-II are struggling to adopt it. Er, well. pgpool is also taking advantage of MD5 weaknesses... While SCRAM

Re: Built-in connection pooling

On 20.04.2018 01:58, Tatsuo Ishii wrote: I think there's plenty things that don't really make sense solving outside of postgres: - additional added hop / context switches due to external pooler This is only applied to external process type pooler (like Pgpool-II). - temporary tables -

Re: Built-in connection pooling

On 19.04.2018 17:27, Dave Cramer wrote: On Thu, Apr 19, 2018, 9:24 AM Konstantin Knizhnik, > wrote: On 19.04.2018 07:46, Tsunakawa, Takayuki wrote: > From: Konstantin Knizhnik [mailto:k.knizh...@postgrespro.ru

Re: Built-in connection pooling

>Development in built-in connection pooling will be continued in https://github.com/postgrespro/postgresql.builtin_pool.git The branch (as of 0020c44195992c6dce26baec354a5e54ff30b33f) passes pgjdbc tests: https://travis-ci.org/vlsi/pgjdbc/builds/368997672 Current tests are mostly

Re: Built-in connection pooling

Christopher>One of the things that they find likable is that by having the connection pool live Christopher>in the framework alongside the application is that this makes it easy to attach Christopher>hooks so that the pool can do intelligent things based on application-aware logic. I'm afraid I

Re: Built-in connection pooling

> On Fri, Apr 20, 2018 at 07:58:00AM +0900, Tatsuo Ishii wrote: >> Yeah. Since SCRAM auth is implemented, some connection poolers >> including Pgpool-II are struggling to adopt it. > > Er, well. pgpool is also taking advantage of MD5 weaknesses... While > SCRAM fixes this class of problems, and

Re: Built-in connection pooling

On Fri, Apr 20, 2018 at 07:58:00AM +0900, Tatsuo Ishii wrote: > Yeah. Since SCRAM auth is implemented, some connection poolers > including Pgpool-II are struggling to adopt it. Er, well. pgpool is also taking advantage of MD5 weaknesses... While SCRAM fixes this class of problems, and channel

Re: Built-in connection pooling

> I think there's plenty things that don't really make sense solving > outside of postgres: > - additional added hop / context switches due to external pooler This is only applied to external process type pooler (like Pgpool-II). > - temporary tables > - prepared statements > - GUCs and other

Re: Built-in connection pooling

On 2018-04-19 15:01:24 -0400, Tom Lane wrote: > Only after you can say "there's nothing wrong with this that isn't > directly connected to its not being in-core" does it make sense to try > to push the logic into core. I think there's plenty things that don't really make sense solving outside of

Re: Built-in connection pooling

Stephen Frost writes: > Greetings, > * Andres Freund (and...@anarazel.de) wrote: >> On 2018-04-18 06:36:38 -0400, Heikki Linnakangas wrote: >>> However, I suspect that dealing with *all* of the issues is going to be hard >>> and tedious. And if there are any significant gaps,

Re: Built-in connection pooling

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2018-04-18 06:36:38 -0400, Heikki Linnakangas wrote: > > On 18/04/18 06:10, Konstantin Knizhnik wrote: > > > But there are still use cases which can not be covered y external > > > connection pooler. > > > > Can you name some? I

Re: Built-in connection pooling

On 2018-04-18 06:36:38 -0400, Heikki Linnakangas wrote: > On 18/04/18 06:10, Konstantin Knizhnik wrote: > > But there are still use cases which can not be covered y external > > connection pooler. > > Can you name some? I understand that the existing external connection > poolers all have their

Re: Built-in connection pooling

On Thu, Apr 19, 2018, 9:24 AM Konstantin Knizhnik, < k.knizh...@postgrespro.ru> wrote: > > > On 19.04.2018 07:46, Tsunakawa, Takayuki wrote: > > From: Konstantin Knizhnik [mailto:k.knizh...@postgrespro.ru] > > Oracle, for example, you can create dedicated and non-dedicated backends. > >> I wonder

Re: Built-in connection pooling

On 19.04.2018 07:46, Tsunakawa, Takayuki wrote: From: Konstantin Knizhnik [mailto:k.knizh...@postgrespro.ru] Oracle, for example, you can create dedicated and non-dedicated backends. I wonder why we do not want to have something similar in Postgres. Yes, I want it, too. In addition to

RE: Built-in connection pooling

From: Konstantin Knizhnik [mailto:k.knizh...@postgrespro.ru] Oracle, for example, you can create dedicated and non-dedicated backends. > I wonder why we do not want to have something similar in Postgres. Yes, I want it, too. In addition to dedicated and shared server processes, Oracle provides

Re: Built-in connection pooling

> 18 апр. 2018 г., в 16:24, David Fetter написал(а): > > On Wed, Apr 18, 2018 at 02:52:39PM +0300, Konstantin Knizhnik wrote: >> Yandex team is following this approach with theirOdysseus >> (multithreaded version of pgbouncer with many of pgbouncer issues >> fixed). > > Have

Re: Built-in connection pooling

On 18.04.2018 16:41, Heikki Linnakangas wrote: On 18/04/18 07:52, Konstantin Knizhnik wrote: On 18.04.2018 13:36, Heikki Linnakangas wrote: On 18/04/18 06:10, Konstantin Knizhnik wrote: But there are still use cases which can not be covered y external connection pooler. Can you name

Re: Built-in connection pooling

On 18/04/18 07:52, Konstantin Knizhnik wrote: On 18.04.2018 13:36, Heikki Linnakangas wrote: On 18/04/18 06:10, Konstantin Knizhnik wrote: But there are still use cases which can not be covered y external connection pooler. Can you name some? I understand that the existing external

Re: Built-in connection pooling

On 18.04.2018 16:24, David Fetter wrote: On Wed, Apr 18, 2018 at 02:52:39PM +0300, Konstantin Knizhnik wrote: Yandex team is following this approach with theirOdysseus (multithreaded version of pgbouncer with many of pgbouncer issues fixed). Have they opened the source to Odysseus? If not,

Re: Built-in connection pooling

On 18.04.2018 16:09, Craig Ringer wrote: On 18 April 2018 at 19:52, Konstantin Knizhnik wrote: As far as I know most of DBMSes have some kind of internal connection pooling. Oracle, for example, you can create dedicated and non-dedicated backends. I wonder why we

Re: Built-in connection pooling

On Wed, Apr 18, 2018 at 02:52:39PM +0300, Konstantin Knizhnik wrote: > Yandex team is following this approach with theirOdysseus > (multithreaded version of pgbouncer with many of pgbouncer issues > fixed). Have they opened the source to Odysseus? If not, do they have plans to? Best, David. --

Re: Built-in connection pooling

On 18 April 2018 at 19:52, Konstantin Knizhnik wrote: > As far as I know most of DBMSes have some kind of internal connection > pooling. > Oracle, for example, you can create dedicated and non-dedicated backends. > I wonder why we do not want to have something similar

Re: Built-in connection pooling

On 18.04.2018 13:36, Heikki Linnakangas wrote: On 18/04/18 06:10, Konstantin Knizhnik wrote: But there are still use cases which can not be covered y external connection pooler. Can you name some? I understand that the existing external connection poolers all have their limitations. But

Re: Built-in connection pooling

On 18/04/18 06:10, Konstantin Knizhnik wrote: But there are still use cases which can not be covered y external connection pooler. Can you name some? I understand that the existing external connection poolers all have their limitations. But are there some fundamental issues that can *only*

Re: Built-in connection pooling

On 17.04.2018 20:09, Nikolay Samokhvalov wrote: Understood. One more question. Have you considered creation of pooling tool as a separate, not built-in tool, but being shipped with Postgres — like psql is shipped in packages usually called “postgresql-client-XX” which makes psql the default

Re: Built-in connection pooling

Understood. One more question. Have you considered creation of pooling tool as a separate, not built-in tool, but being shipped with Postgres — like psql is shipped in packages usually called “postgresql-client-XX” which makes psql the default tool to work in terminal? I constantly hear opinion

Re: Built-in connection pooling

On 13.04.2018 19:07, Nikolay Samokhvalov wrote: On Fri, Apr 13, 2018 at 2:59 AM, Konstantin Knizhnik > wrote: Development in built-in connection pooling will be continued in

Re: Built-in connection pooling

On Fri, Apr 13, 2018 at 2:59 AM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > > Development in built-in connection pooling will be continued in > https://github.com/postgrespro/postgresql.builtin_pool.git > I am not going to send new patches to hackers mailing list any more. > Why?

Re: Built-in connection pooling

On 06.04.2018 20:03, Konstantin Knizhnik wrote: On 06.04.2018 20:00, Konstantin Knizhnik wrote: Attached please find new version of the patch with  several bug fixes + support of more than one session pools associated with different ports. Now it is possible to make postmaster listen

Re: Built-in connection pooling

On 06.04.2018 20:00, Konstantin Knizhnik wrote: Attached please find new version of the patch with  several bug fixes + support of more than one session pools associated with different ports. Now it is possible to make postmaster listen several ports for accepting pooled connections, while

Re: Built-in connection pooling

Attached please find new version of the patch with  several bug fixes + support of more than one session pools associated with different ports. Now it is possible to make postmaster listen several ports for accepting pooled connections, while leaving main Postgres port for dedicated backends.

Re: Built-in connection pooling

On Fri, Feb 9, 2018 at 4:14 PM, Shay Rojansky wrote: > Am a bit late to this thread, sorry if I'm slightly rehashing things. I'd > like to go back to the basic on this. > > Unless I'm mistaken, at least in the Java and .NET world, clients are > almost always expected to have their

Re: Built-in connection pooling

Am a bit late to this thread, sorry if I'm slightly rehashing things. I'd like to go back to the basic on this. Unless I'm mistaken, at least in the Java and .NET world, clients are almost always expected to have their own connection pooling, either implemented inside the driver (ADO.NET model)

Re: Built-in connection pooling

Attached please find new version of built-in connection pooling supporting temporary tables and session GUCs. Also Win32 support was added. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/src/backend/catalog/namespace.c

Re: Built-in connection pooling

Konstantin>I do not have explanation of performance degradation in case of this particular workload. A) Mongo Java Client uses a connection-pool of 100 connections by default. That is it does not follow "connection per client" (in YCSB terms), but it is capped by 100 connections. I think it can

Re: Built-in connection pooling

On 01.02.2018 23:28, Vladimir Sitnikov wrote: > config/pgjsonb-local.dat Do you use standard "workload" configuration values? (e.g. recordcount=1000, maxscanlength=100) Yes, I used default value for workload. For example, workload-A has the following settings: # Yahoo! Cloud System

Re: Built-in connection pooling

On 01.02.2018 16:33, Vladimir Sitnikov wrote: Konstantin>I have not built YCSB myself, use existed installation. Which pgjdbc version was in use? postgresql-9.4.1212.jar Konstantin>One of the main problems of Postgres is significant degrade of performance in case of concurrent write

Re: Built-in connection pooling

Konstantin>I have not built YCSB myself, use existed installation. Which pgjdbc version was in use? Konstantin>One of the main problems of Postgres is significant degrade of performance in case of concurrent write access by multiple transactions to the same sows. I would consider that a

Re: Built-in connection pooling

On 01.02.2018 15:21, Vladimir Sitnikov wrote: Konstantin>I have obtained more results with YCSB benchmark and built-in connection pooling Could you provide more information on the benchmark setup you have used? For instance: benchmark library versions, PostgreSQL client version,

Re: Built-in connection pooling

Konstantin>I have obtained more results with YCSB benchmark and built-in connection pooling Could you provide more information on the benchmark setup you have used? For instance: benchmark library versions, PostgreSQL client version, additional/default benchmark parameters. Konstantin>Postgres

Re: Built-in connection pooling

I have obtained more results with YCSB benchmark and built-in connection pooling. Explanation of the benchmark and all results for vanilla Postgres and Mongo are available in Oleg Bartunov presentation about  JSON (at the end of presentation):

Re: Built-in connection pooling

Bruce>Well, we could have the connection pooler disconnect those, right? I agree. Do you think we could rely on all the applications being configured in a sane way? A fallback configuration at DB level could still be useful to ensure the DB keeps running in case multiple applications access it.

Re: Built-in connection pooling

On Mon, Jan 29, 2018 at 04:02:22PM +, Vladimir Sitnikov wrote: > Bruce>Yes, it would impact applications and you are right most applications > could not handle that cleanly. > > I would disagree here. > We are discussing applications that produce "lots of idle" connections, aren't > we? That

Re: Built-in connection pooling

Bruce>Yes, it would impact applications and you are right most applications could not handle that cleanly. I would disagree here. We are discussing applications that produce "lots of idle" connections, aren't we? That typically comes from an application-level connection pool. Most of the

Re: Built-in connection pooling

On Mon, Jan 29, 2018 at 11:57:36AM +0300, Konstantin Knizhnik wrote: > Right now, if you hit max_connections, we start rejecting new > connections. Would it make sense to allow an option to exit idle > connections when this happens so new users can connect? > > It will require

Re: Built-in connection pooling

On 28.01.2018 03:40, Bruce Momjian wrote: On Mon, Jan 22, 2018 at 06:51:08PM +0100, Tomas Vondra wrote: Yes, external connection pooling is more flexible. It allows to perform pooling either at client side either at server side (or even combine two approaches).> Also external connection

Re: Built-in connection pooling

On Sun, Jan 28, 2018 at 03:11:25PM -0800, Ivan Novick wrote: > > The simplest thing sounds like a GUC that will automitcally end a connection > > > idle for X seconds. > > Uh, we already have idle_in_transaction_session_timeout so we would just > need a simpler version. > > > Oh i

Re: Built-in connection pooling

> The simplest thing sounds like a GUC that will automitcally end a connection > > idle for X seconds. > > Uh, we already have idle_in_transaction_session_timeout so we would just > need a simpler version. > Oh i see its in 9.6, AWESOME! Cheers

Re: Built-in connection pooling

On Sat, Jan 27, 2018 at 4:40 PM, Bruce Momjian wrote: > On Mon, Jan 22, 2018 at 06:51:08PM +0100, Tomas Vondra wrote: > Right now, if you hit max_connections, we start rejecting new > connections. Would it make sense to allow an option to exit idle > connections when this

Re: Built-in connection pooling

On Mon, Jan 22, 2018 at 06:51:08PM +0100, Tomas Vondra wrote: > > Yes, external connection pooling is more flexible. It allows to > > perform pooling either at client side either at server side (or even > > combine two approaches).> > > Also external connection pooling for PostgreSQL is not

Re: Built-in connection pooling

On 01/22/2018 05:05 PM, Konstantin Knizhnik wrote: > > > On 19.01.2018 20:28, Tomas Vondra wrote: >>> >>> With pgbouncer you will never be able to use prepared statements which >>> slows down simple queries almost twice (unless my patch with >>> autoprepared statements is committed). >>> >> I

Re: Built-in connection pooling

On 19.01.2018 20:28, Tomas Vondra wrote: With pgbouncer you will never be able to use prepared statements which slows down simple queries almost twice (unless my patch with autoprepared statements is committed). I don't see why that wouldn't be possible? Perhaps not for prepared statements

Re: Built-in connection pooling

On 01/19/2018 07:35 PM, Claudio Freire wrote: > > > On Fri, Jan 19, 2018 at 2:22 PM, Tomas Vondra > > wrote: > > > > On 01/19/2018 06:13 PM, Claudio Freire wrote: > > > > > > On Fri, Jan 19, 2018 at 2:07 PM,

Re: Built-in connection pooling

On Fri, Jan 19, 2018 at 2:22 PM, Tomas Vondra wrote: > > > On 01/19/2018 06:13 PM, Claudio Freire wrote: > > > > > > On Fri, Jan 19, 2018 at 2:07 PM, Konstantin Knizhnik > > > wrote: > > > > > > > > > >

Re: Built-in connection pooling

On 01/19/2018 06:07 PM, Konstantin Knizhnik wrote: > > ... > 3) Is there any sort of shrinking the pools? I mean, if the backend is idle for certain period of time (or when we need backends for other databases), does it get closed automatically? >>> When client is

  1   2   >