MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "Source_code_repository",
        "continue": "gapcontinue||"
    },
    "query": {
        "pages": {
            "146": {
                "pageid": 146,
                "ns": 0,
                "title": "Relationship between max pool, num init children, and max connections",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "Gurjeet Singh (last updated: 22 August 2012)\n\nmax_pool parameter configures how many connections to cache _per\nchild_. So if num_init_children is configured to 100, and max_pool is\nconfigured to 3, then pgpool can potentially open 300 (=3*100) connections\nto the backend database.\n\nA child process opens a new backend connection only if the requested\n[user,database] pair is not already in the cache. So if the application\nuses only one user to connect to only one database, say [pguser1,pgdb1],\nthen each child will continue to reuse the first connection and will never\nopen a second connection, so in effect pgpool will open no more than 100\nbackend connections even though max_pool is set to 3.\n\nBut if the application uses more than one pair of [user,database]\nconnection parameters, then each child will cache the connection it might\nalready have for another pair, and open a new backend connection for the\nrequested pair.\n\nFor eg., if the application now uses these 4 pairs: [user1,db1]\n[user1,db2] [user2,db1] [user2,db2] to connect to pgpool, then each child\nprocess can cache up to 3 connections for the first 3 different pairs it\nreceives connection requests for. But as soon as it receives a request for\nthe 4th pair that it does not yet have a connection for, then it will\ndisconnect the oldest connection in the cache and open a new connection for\nthe 4th pair.\n\nAs we already know that there's no guarantee as to which child process\nwill handle an incoming connection request, max_pool tries to improve the\nperformance a little bit by caching connections of different pairs, in the\nhopes that an incoming connection request might match one of the\nconnections cached by the child process. But this also causes an explosion\nin the number of connections that pgpool would request from the database.\n\nSo, in order to guarantee that the application connection requests are\nnever rejected, and that the connection requests wait until a database\nconnection is available, the following condition should be met:\n\n max_pool*num_init_children <= (max_connections - superuser_reserved_connections)\n\nIf the application uses superuser connections (which is not\nrecommended), then the condition is reduced to:\n\n max_pool*num_init_children <= max_connections\n\nSetting max_pool to 1 will guarantee that the number of database\nconnections opened by pgpool child processes never exceeds the\nnum_init_children value. If for performance reasons, as explained above,\nyou do wish to set max_pool to more than 1, then max_connections will also\nhave to be increased accordingly so that application connection requests do\nnot get denied."
                    }
                ]
            },
            "517": {
                "pageid": 517,
                "ns": 0,
                "title": "Roadmap",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "== Upcoming minor releases == \n\nPgPool Global Development Group will make at least one minor release quarterly according to a predefined schedule.\n\nIf there are important bug fixes or security issues, more releases will be made between these scheduled dates.\n\nThe current schedule for upcoming releases is: \n\n* February 29th, 2024\n* May 16th, 2024\n* August 15th, 2024\n* November 21st, 2024"
                    }
                ]
            }
        }
    }
}