Playing with Elephants ~PostgreSQL and Pgpool-II~

In the previous post , I explained how to control the client connections by using reserved_connections parameter. In this post I would like to introduce how to use shared relation cache to improve performance. Shared relation cache is added in Pgpool-II 4.1. Before explaining this feature, let's have a look at what relation cache of Pgpool-II is. What is relation cache? If Pgpool-II receives a client query, Pgpool-II will parse the query and extract the table name, then access PostgreSQL system catalogs to get the relation information. Pgpool-II obtains the following information from PostgreSQL system catalogs: whether a table included in the query is a temporary table or not whether a table included in the query is an unlogged table or not whether a function included in the query is "immutable" or not (if a function is used in the query and query cache mode is enabled) If the table included in the query is a temporary table or an unlogged table, then Pgpool-II must sen...

Pgpool-II is a feature-rich PostgreSQL cluster management tool. To determine which configuration is best for your database cluster, you need to understand the purpose of the parameters. Since this blog, I will introduce several effective parameters to improve performance. In this blog, I will explain reserved_connections parameter and how to configure this parameter. This parameter is used to refuse the incoming client connections with error message "Sorry, too many clients already" rather than block it, when the number of client connections exceeds the value of "num_init_children - reserved_connections" .  First, let me describe why this parameter is added. Control of client connections in Pgpool-II 4.0 and earlier At startup, Pgpool-II parent process preforks num_init_children child processes, and each child process is waiting for a client connection. If the maximum number of concurrent client connections (the value of num_init_children ) has been reached, how...