It would be great to know how many connections you spect to handle at the same time.
I would size this depending on your server hardware use expectations
If you expect 1024 concurrent connections as much this setting is correct.
max_client_conn = 1024
But here are the changes that worked for me. If you change the pooling mode you can reduce the default_pool_size, this increased my performance
pool_mode = transaction
default_pool_size = 50
Take a look at the different pooling modes to see if you can benefit from a more efficient pooling mode than the default value session pool mode.
Most polite method. When client connects, a server connection will be assigned to it for the whole duration it stays connected. When client disconnects, the server connection will be put back into pool. This mode supports all PostgeSQL features.
Transaction pooling Server connection is assigned to client only
during a transaction. When PgBouncer notices that transaction is over,
the server will be put back into pool.
This mode breaks few session-based features of PostgreSQL. You can use
it only when application cooperates by not using features that break.
See the table below for incompatible features.
Statement pooling Most
aggressive method. This is transaction pooling with a twist -
multi-statement transactions are disallowed. This is meant to enforce
"autocommit" mode on client, mostly targeted for PL/Proxy.