I have a table of records that is populated sequentially once, but then every record is updated (the order in which they are updated and the timing of the updates are both random). The updates are not HOT updates. Is there any advantage to setting my fillfactor for this table to 50, or even less than 50, given these facts?
Postgres: Set fillfactor to 50?
3.7k Views Asked by carbocation At
1
There are 1 best solutions below
Related Questions in POSTGRESQL
- Can MVC.NET prevent SQL-injection at razor or controller level?
- Getting and passing MVC Model data to AngularJS controller
- Access property of an object of type [Model] in JQuery
- Entity Framework Code First with Fluent API Concurrency `DbUpdateConcurrencyException` Not Raising
- Bundling and minification issue in MVC
- ASP-MVC Code-first migrations checkbox not active
- Why does Azure CloudConfigurationManager.GetSetting return null
- Dynamic roles list in CustomAuthorize ASP MVC
- Jquery: Change contents of <select> tag dynamically
- Why web API return 404 when deploy to IIS
Related Questions in FILLFACTOR
- Can MVC.NET prevent SQL-injection at razor or controller level?
- Getting and passing MVC Model data to AngularJS controller
- Access property of an object of type [Model] in JQuery
- Entity Framework Code First with Fluent API Concurrency `DbUpdateConcurrencyException` Not Raising
- Bundling and minification issue in MVC
- ASP-MVC Code-first migrations checkbox not active
- Why does Azure CloudConfigurationManager.GetSetting return null
- Dynamic roles list in CustomAuthorize ASP MVC
- Jquery: Change contents of <select> tag dynamically
- Why web API return 404 when deploy to IIS
Trending Questions
- UIImageView Frame Doesn't Reflect Constraints
- Is it possible to use adb commands to click on a view by finding its ID?
- How to create a new web character symbol recognizable by html/javascript?
- Why isn't my CSS3 animation smooth in Google Chrome (but very smooth on other browsers)?
- Heap Gives Page Fault
- Connect ffmpeg to Visual Studio 2008
- Both Object- and ValueAnimator jumps when Duration is set above API LvL 24
- How to avoid default initialization of objects in std::vector?
- second argument of the command line arguments in a format other than char** argv or char* argv[]
- How to improve efficiency of algorithm which generates next lexicographic permutation?
- Navigating to the another actvity app getting crash in android
- How to read the particular message format in android and store in sqlite database?
- Resetting inventory status after order is cancelled
- Efficiently compute powers of X in SSE/AVX
- Insert into an external database using ajax and php : POST 500 (Internal Server Error)
Popular # Hahtags
Popular Questions
- How do I undo the most recent local commits in Git?
- How can I remove a specific item from an array in JavaScript?
- How do I delete a Git branch locally and remotely?
- Find all files containing a specific text (string) on Linux?
- How do I revert a Git repository to a previous commit?
- How do I create an HTML button that acts like a link?
- How do I check out a remote Git branch?
- How do I force "git pull" to overwrite local files?
- How do I list all files of a directory?
- How to check whether a string contains a substring in JavaScript?
- How do I redirect to another webpage?
- How can I iterate over rows in a Pandas DataFrame?
- How do I convert a String to an int in Java?
- Does Python have a string 'contains' substring method?
- How do I check if a string contains a specific word?
Ok, as you mentioned in the comments to your question, you're making changes in your table using transactions updating 1-10k records in each transaction. This is right approach leaving some chances to autovacuum to make its work. But table's
fillfactor
is not the first thing I'd check/change. Fillfactor can help you to speed up the process, but if autovacuum is not aggressive enough, you'll get very bloated table and bad performance soon.So, first, I'd suggest you to control your table's bloating level. There is a number of queries which can help you:
Next, I'd tune autovacuum to much more aggressive state than default, like this (this is usually good idea even if you don't need to process whole table in short period of time), something like this:
After some significant number of transactions with UPDATEs, check the bloating level.
Finally, yes, I'd tune fillfactor but probably to some higher (and more usual) value like 80 or 90 – here you need to make some predictions, what is the probability that 10% or more tuples inside a page will be updated by the single transaction? If the chances are very high, reduce fillfactor. But you've mentioned that order of rows in UPDATEs is random, so I'd use 80-90%. Keep in mind that there is an obvious trade-off here: if you set fillfactor to 50, your table will need 2x more disk space and all operations will naturally become slower. If you want to go deep to this question, I suggest creating 21 tables with fillfactors 50..100 with the same data and testing UPDATE TPS with pgbench.