max_connections documentation

Started by Jim Nasbyabout 11 years ago3 messages
#1Jim Nasby
Jim.Nasby@BlueTreble.com

I'm surprised to see that the docs make no mention of how max_connections, max_worker_processes and autovacuum_max_workers (don't) relate. I couldn't remember and had to actually look at the code. I'd like to clarify this in the max_connecitons section of the documents by doing s/connections/user connections/ and including the formula for MaxBackends (MaxBackends = MaxConnections + autovacuum_max_workers + 1 + max_worker_processes). I'll also mention that any postgres_fdw connections are considered user connections.

Objections? Comments?

Also, my understanding is that the parallel stuff will continue to fall under max_worker_processes?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#2Amit Kapila
amit.kapila16@gmail.com
In reply to: Jim Nasby (#1)
Re: max_connections documentation

On Sat, Jan 10, 2015 at 6:20 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:

I'm surprised to see that the docs make no mention of how

max_connections, max_worker_processes and autovacuum_max_workers (don't)
relate. I couldn't remember and had to actually look at the code. I'd like
to clarify this in the max_connecitons section of the documents by doing
s/connections/user connections/ and including the formula for MaxBackends
(MaxBackends = MaxConnections + autovacuum_max_workers + 1 +
max_worker_processes). I'll also mention that any postgres_fdw connections
are considered user connections.

I think it makes sense to add such a clarification in docs, however
not sure if specifying along with max_connections parameter is
good idea as the formula is somewhat internal and is not directly
related to max_connections. How about specifying in below page:

http://www.postgresql.org/docs/devel/static/connect-estab.html

Also, my understanding is that the parallel stuff will continue to fall

under max_worker_processes?

Yes.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

#3Jim Nasby
Jim.Nasby@BlueTreble.com
In reply to: Amit Kapila (#2)
Re: max_connections documentation

On 1/10/15 12:06 AM, Amit Kapila wrote:

On Sat, Jan 10, 2015 at 6:20 AM, Jim Nasby <Jim.Nasby@bluetreble.com <mailto:Jim.Nasby@bluetreble.com>> wrote:

I'm surprised to see that the docs make no mention of how max_connections, max_worker_processes and autovacuum_max_workers (don't) relate. I couldn't remember and had to actually look at the code. I'd like to clarify this in the max_connecitons section of the documents by doing s/connections/user connections/ and including the formula for MaxBackends (MaxBackends = MaxConnections + autovacuum_max_workers + 1 + max_worker_processes). I'll also mention that any postgres_fdw connections are considered user connections.

I think it makes sense to add such a clarification in docs, however
not sure if specifying along with max_connections parameter is
good idea as the formula is somewhat internal and is not directly
related to max_connections.

It's not all that internal; it directly controls how many entries you could end up with in pg_stat_activity. Certainly monitoring software needs to be aware of how this stuff works, and I think many DBAs would want to know as well. Maybe we don't need the formula itself, but we need to explain what backends do not count towards max_connections (and ideally how to identify them).

Maybe the best thing would be to add an "internal" field to pg_stat_activity to indicate what backends were internal and not user-related...

How about specifying in below page:

http://www.postgresql.org/docs/devel/static/connect-estab.html

I think someone that's concerned about connection limits is much more likely to look at the config section of the docs than that section, so we'd need to cross-reference them. Which would probably be good to do anyway...
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers