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 March PostgreSQL: The Awesome Table Fillfactor to speedup UPDATE and SELECT statement

PostgreSQL: The Awesome Table Fillfactor to speedup UPDATE and SELECT statement

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

PostgreSQL Table FillFactor

This is one of the most important articles for all PostgreSQL Database Professionals because it relates to PostgreSQL database optimization

 

 

 

First, You guys have to know what is MVCC and how it manages the different row versions.

What is Fillfactor and how it impacts the performance?

The Fillfactor is a table storage parameter and for the performance aspect this is the most important parameter.

The Fillfactor for a table is a percentage between 10 and 100. 100 is the default for a complete packing.

Because of this default 100 value, when one UPDATE is performed, the old tuple is marked as deleted and a new tuple is inserted into another page.
There is no extra space to write a new tuple on the same page because default 100 means write data in page till its full.

Now, next impact of this default 100 is, related indexes of newly updated records are modified because it has to point to the new page location.

If you notice here, for one UPDATE actually there are three operations, first mark deleted tuples, write new tuples in the new pages, and index modifications.

This is not just about the UPDATE but actually the performance of SELECT query also will degrade because of the internal fragmentation.

How can we improve the performance?6

The default Fillfactor is 100 and it is better, but not in all situations.
When your table has frequent updates, this is not a better solution because it requires more CPU and IO for different data page operations which actually degrade the performance.

The solution is to first measure the size of the tuple and if tuple size is not that much bigger, we can reduce the value of default Fillfactor.

How to measure the size of the tuple in PostgreSQL?

How to change the current value of Table Fillfactor in PostgreSQL?

When we reduce the default value of Fillfactor, each page has some free space and new tuple which is generated by UPDATE can be stored on the same page.

Now, index page does not require any modification because new tuple is on the same page.

Mar 28, 2016Anvesh Patel
SQL Server: How to read database error log using T-SQL (xp_readerrorlog)PostgreSQL: How to measure the size of a Table Row and Data Page?
Comments: 5
  1. bon
    March 30, 2016 at 5:33 am

    Good way of describing, and fastidious piece of writing to get data
    regarding my presentation subject matter, which i am going
    to deliver in college.

  2. Venkatesh Naicker
    October 12, 2016 at 6:02 pm

    Hi Anvesh. Your post on the fill factor is interesting. You mentioned three i/o for an update with fill factor of 100 (1. delete original tuple, 2. insert new tuple on the new page, 3. update index). Now when there is fill factor of 70, doesn’t it still need to delete original tuple and insert the new tuple (though on the same page)? Is it saving on index update because on the same page? I am a bit lost? Thanks!

    • Anvesh Patel
      Anvesh Patel
      October 12, 2016 at 6:03 pm

      Hello Venkatesh,
      Thanks for you appreciation !
      When we are talking about same page operation, index pointer does not require to move from one page to another. Yes, It reduces most of I/O cost. Its also reduces the internal fragmentation.

      • Dima
        July 16, 2017 at 1:52 pm

        It should be good to mention, that this only works when updates do not touch indexed columns.
        When update touches indexed column(s), postgres should add new tuples to all table indexes to point to new version.

  3. Ayushi
    July 4, 2017 at 10:08 am

    Simple and easily understandable terms and language
    Thanks šŸ™‚

Anvesh Patel
Anvesh Patel

Database Engineer

March 28, 2016 PostgreSQLAnvesh Patel, database, database research and development, dbrnd, Fillfactor, plpgsql, Postgres Query, postgresql, PostgreSQL Administrator, PostgreSQL Error, PostgreSQL Programming, PostgreSQL Tips and Tricks
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....