Does the pool support "idle" connection ? about r2d2 HOT 14 CLOSED

There are now three new configuration options.

• idle_timeout Connections will be destroyed if they are left idle for this long
• max_lifetime Connections will be destroyed after they have existed for this period of time
• min_idle The pool will try to keep this many connections idle at all times. This is the option you'll drop below pool_size if you want a variable sized pool

Seem like that'll work?

from r2d2.

The pool maintains a fixed number of connections, which is specified via the pool_size field of the config: http://sfackler.github.io/r2d2/doc/v0.6.1/r2d2/config/struct.Builder.html#method.pool_size

from r2d2.

oh then my question is reversed : how can i set the maximun number of connection my pool will reach ?

i.e is it possible to have both "set max idle connection" and "set max open connection" like in go

https://golang.org/pkg/database/sql/#DB.SetMaxIdleConns
https://golang.org/pkg/database/sql/#DB.SetMaxOpenConns

from r2d2.

pool_size corresponds to MaxOpenConns. There is no equivalent to MaxIdleConns.

from r2d2.

I see, is it something that you think may be useful to implement ?

from r2d2.

It's not totally clear to me what purpose MaxIdleConns is supposed to serve. What's the use case for wanting to adjust it?

from r2d2.

actually it's a pretty frequent use case, at least in the companies I've worked

you have a database used by several systems, or like in amazon, with a hard limited number of connection
so you want to have your MaxOpenConns to be sure to not reach this hard limit.
However, your services is only used in burst (for example once every hour or so) so you don't want to keep MaxOpenConns open all the times because it will be a waste of resource (as your other services may not have their burst moment at the same time) but you don't want all the connection to be garbage collected/timeout as it would meant:

1. the X first connections will be a little slower the time the connection to the db is opened
2. all the connections may already have been used in the meantime by an other service in burst time, so this way you're sure to be able to provide an access to the database.

this carefull management of number of connection opened is especially important in cloud-based services, where your postgresql instance are priced by number of max connection, and from one instance size to an other you can easily double or halfed the price

from r2d2.

At least for Amazon RDS, you're billed based on hardware and storage requirements, not active connections, right? For some workload, there is an optimal number of connections at which throughput and cost is optimal. What is the downside in maintaining exactly that number of connections at all times? What are the resources being conserved for?

In any case, I'm not so opposed to allowing the pool size to be non-fixed, but I'm not sure what the configuration parameter should be. Go's pool has SetMaxOpenConns and SetMaxIdleConns, HikariCP has minimumIdle and maximumPoolSize. c3p0 has maxPoolSize, minPoolSize, and some other parameters to configure how connections are added and dropped. Go's setup seems like it would cause a lot of thrashing if load is bouncing above and below the MaxIdleConns threshold.

from r2d2.

The main argument I got for that is that by keeping a number > 0 (and < Max pool size) of connection at anytime, you prevent yourself from being starved by other application (while trying to not be too greedy by keeping it < Max pool size)

from r2d2.

As for RDS, my bad, I discovered only today that it's possible to change the max number of connection (cargo cult in my team), but as it's not something that can be changed dynamically, my point above still stands

from r2d2.

I think I'm leaning towards the Hikari/c3p0 config strategy, though those will require some more functionality to be added that I've been meaning to do for a while (max idle time, for example).

from r2d2.

ok great, thanks :)

from r2d2.

awesome , yes it should do the trick

from r2d2.

Released v0.6.2 with these changes.

from r2d2.