Postgres Autovacuum is Not the Enemy
citusdata.com
Postgres Autovacuum is Not the Enemy
1–10 of 16 posts
Re: Postgres Autovacuum is Not the Enemy
#2The main problem here is that autovacuum threshold is something like c + m * nrows, and in large configurations you could have all sorts of table sizes.
How much change is a lot? 1% of the table + 50 rows (for small tables)? I would argue that sometimes is better to use a fixed threshold, e.g. c = 1000, m=0
All these approaches are hit or miss and are different per configuration. What I found useful is to choose the best parameters you can think of without forcing autovacuum to run everytime, and have an external job run vacuum manually to cleanup whatever got missed... eventually you can figure out the right configuration.
Re: Postgres Autovacuum is Not the Enemy
#3The actual title of the article is "Postgres Autovacuum is Not the Enemy". The word "Postgres" is a critical element here and should not be left off.
Re: Postgres Autovacuum is Not the Enemy
#4The main problem here is that autovacuum threshold is something like c + m * nrows, and in large configurations you could have all sorts of table sizes. How much change is a lot? 1% of the table + 50 rows (for small tables)? I would argue that sometimes is better to use a fixed threshold, e.g. c = 1000, m=0 All these approaches are hit or miss and are different per configuration. What I found useful is to choose the…
I think the idea for this is either tune it for your problem cases, or if it's an issue at your scale, divide and conqueror your use case (small tables in one physical DB, large tables in another).
Re: Postgres Autovacuum is Not the Enemy
#5The actual title of the article is "Postgres Autovacuum is Not the Enemy". The word "Postgres" is a critical element here and should not be left off.
Yeah, I came up with some pretty dark stuff trying to imagine what an "autovacuum" was.
Re: Postgres Autovacuum is Not the Enemy
#6I find the recommendation to leave the cost limit alone strange. The problem is this is a global limit, shared by all autovacuum workers. The default (200) means all workers combined should not do more than 8 MB/s reads or 4 MB/s writes, which on current hardware are rather low limits. Increasing the number of workers is good, but the total autovacuum throughput does not change - there will be more workers but they'll go slower.
Also a note regarding the delay - the resolution really depends on hardware. Some timers have only 10ms resolution, for example.
Re: Postgres Autovacuum is Not the Enemy
#7Unreadable in portrait on mobile?
How does one even begin to think that blocking users from scrolling horizontally on your site is a good idea?
Re: Postgres Autovacuum is Not the Enemy
#8Unreadable in portrait on mobile? How does one even begin to think that blocking users from scrolling horizontally on your site is a good idea?
Indeed. overflow: hidden on the parent combined with float: left on the main text - it's bizarre. Why would someone take the whole content of the page out of the main flow like that?
It's also using some kind of javascript callbacks to get responsive placement of the header, rather than media queries.
Re: Postgres Autovacuum is Not the Enemy
#9The actual title of the article is "Postgres Autovacuum is Not the Enemy". The word "Postgres" is a critical element here and should not be left off.
Yeah, I came up with some pretty dark stuff trying to imagine what an "autovacuum" was.
I thought someone was finally sticking up for Roombas.
Re: Postgres Autovacuum is Not the Enemy
#10Site text gets cut off on mobile