Some more thoughts on random_page_cost
The author discusses the complexities of tuning the 'random_page_cost' parameter in PostgreSQL databases. It examines why historical defaults may no longer align with modern SSD performance and how cost models often fail to account for caching effects.
Why it matters
Optimizing database configuration parameters is essential for maintaining high-performance infrastructure in data-intensive applications.
A couple months back I posted about maybe adjusting random_page_cost to better reflect how current storage handles random and sequential access. I had a bunch of great discussions about the topic since then, but ultimately I got distracted by other stuff.
POSETTE happened last week, with my pre-recorded talk about this very topic (and many other great talks, BTW). Which reminded me that I started thinking about random_page_cost a bit differently. So here’s an update with some more thoughts.
I did already touch on some of these things in the old post, and then also in the POSETTE talk in more detail.
Get smarter about the news
Sign up free for a feed built around what you actually care about, Dive Deeper research on any story, and the full text of every article.
Create free accountAlready have an account? Sign in