Database Research & Development

  • Home
  • NoSQL
    • NoSQL
    • Cassandra
  • Databases
    • Database Theory
    • Database Designing
    • SQL Server Coding Standards
    • SQL Server
    • PostgreSQL
    • MySQL
    • Greenplum
    • Linux
  • Interviews
    • SQL Server Interviews
    • MySQL Interviews
    • SQL Puzzles
  • DBA Scripts
    • SQL Server DBA Scripts
    • PostgreSQL DBA Scripts
    • MySQL DBA Scripts
    • Greenplum DBA Scripts
  • Home
  • Blog Archives !
  • (: Laugh@dbrnd :)
  • Contact Me !
sqlserverinterviews
Home 2016 February PostgreSQL: Important Parameters for better Performance

PostgreSQL: Important Parameters for better Performance

This article is half-done without your Comment! *** Please share your thoughts via Comment ***

In this post, I am sharing few important parameters for tunning the PostgreSQL for better performance.

When we are writing SQL, we are doing our best and trying to write database optimized code.
We are also checking Indexes and best execution plan, and accordingly, we are making our SQL queries.

But sometimes, we are not getting the good performance so at that time we should look at PostgreSQL Server level configuration and parameters.

Below are important parameters:
You can set all parameters in postgresql.conf file.

max_connections:
We can configure the maximum number of client connections and this is very important because every connection requires memory and other resources.
PostgreSQL can handle some hundred of connections, but if we are planning for thousands of connections, we should use some connection pooling mechanism to reduce overhead of connections.

shared_buffers:
Instead of big shared memory pool, PostgreSQL has a separate process for each database connection. PostgreSQL uses this dedicated memory area for caching purpose, so its provide lots of performance gain in your system.

If we have more loads, we can set large values for shared_buffers.
Generally, we should set shared_buffers values up to 1/4 part of the main memory.

You can calculate using, below formula

(0.25 * Main Memory)

wal_buffers:
This parameter defines, how much space is required for caching to write-ahead log entries. This is really very small size value but it is required to change in heavily loaded servers.

Recommended value is: 8MB.

work_mem:
This is also one of the most important parameter which is used to set a private work space for each and every new connection.
We have shared_buffers which we are using as the dedicated buffer for all connections, but using work_mem we can set memory for each query.

If we have configured wrongly, it really creates a big problem for us because if we have a big, complex query and which is running for multiple times then it will create a big problem for us.

We should configure this parameter base on the number of connections and what type of queries we are running on the server.

We can calculate using this method,
Memory(MB) / Max_connections.
If the result is very near to Max_connections, perform the divide by 2 again.

The result should be at least 16MB otherwise we should buy more RAM.

maintenance_work_mem:
This is also same as like work_mem parameter, but use only for maintenance related queries like, VACUUM, CLUSTER.
Generally, we are doing maintenance when query load is not too high.
I suggest you set a big value for parameter so that we can quickly complete our maintenance task.

Default is 16MB and Recommended is (Memory / 8).

effective_cache_size:
This parameter is mostly dedicated to PostgreSQL query planner because query planner is responsible to execute a query by choosing a better optimized execution path.
The query planner also requires some space to perform their work so this parameter helps the query planner.

Default is 65536 and Recommended is (Memory (MB) * 0.75)

autovacuum:
This is also one of the important parameter because PostgreSQL support MVCC nature.
This is really very required and it solves lots of performance related issues by removing dead tuples.
Whenever table is free, Autovacuum performs vacuuming on that table so another individual Vacuum executes fast because it has very less to remove.

synchronous_commit:
You can set number of transactions to commit per second. e.g. set 100 transaction means per second, 100 transactions is going to commit.
This parameter should be ON or OFF is up to our choice because when we put OFF, our bulk insertion is faster, but there is the chance of failure and when we put ON, bulk insertion may slow down but the chance of data failure is also very less.

Feb 9, 2016Anvesh Patel
SQL Server 2012: Introduced LAG function, the best alternative of Self Join to compare Previous RowMySQL: Perform Case Sensitive string comparison
Comments: 2
  1. Puneet
    July 17, 2018 at 12:27 pm

    How to calculate max_connections in postgresql

    • Anvesh Patel
      Anvesh Patel
      July 17, 2018 at 7:07 pm

      It depends on your system usage. You can use pgbench for testing the load of actual user connections. Below is a reference link,

      https://www.dbrnd.com/2018/04/postgresql-use-pgbench-for-testing-the-load-performance-of-server/

Anvesh Patel
Anvesh Patel

Database Engineer

February 9, 2016 PostgreSQLAnvesh Patel, autovacuum, database, database research and development, dbrnd, effective_cache_size, maintenance_work_mem, plpgsql, Postgres Query, postgresql, PostgreSQL Administrator, PostgreSQL Error, PostgreSQL Programming, PostgreSQL Tips and Tricks, shared_buffers, synchronous_commit
About Me!

I'm Anvesh Patel, a Database Engineer certified by Oracle and IBM. I'm working as a Database Architect, Database Optimizer, Database Administrator, Database Developer. Providing the best articles and solutions for different problems in the best manner through my blogs is my passion. I have more than six years of experience with various RDBMS products like MSSQL Server, PostgreSQL, MySQL, Greenplum and currently learning and doing research on BIGData and NoSQL technology. -- Hyderabad, India.

About DBRND !

dbrnd

This is a personal blog (www.dbrnd.com).

Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated.

Feel free to challenge me, disagree with me, or tell me I’m completely nuts in the comments section of each blog entry, but I reserve the right to delete any comment for any reason whatsoever (abusive, profane, rude, or anonymous comments) - so keep it polite.

The content of this website is protected by copyright. No portion of this website may be copied or replicated in any form without the written consent of the website owner.

Recent Comments !
  • Anvesh Patel { Sure will do... } – May 27, 12:43 PM
  • Anvesh Patel { Great... } – May 27, 12:41 PM
  • Anvesh Patel { Great... } – May 27, 12:39 PM
  • Anvesh Patel { Great... } – May 27, 12:36 PM
  • Anvesh Patel { Great... } – May 27, 12:28 PM
  • Anvesh Patel { Great... } – May 27, 12:27 PM
  • Anvesh Patel { Great... } – May 27, 12:16 PM
  • Older »
Follow Me !
  • facebook
  • linkedin
  • twitter
  • youtube
  • google
  • flickr
© 2015 – 2019 All rights reserved. Database Research & Development (dbrnd.com)
Posting....