A Performance Cheat Sheet for PostgreSQL
severalnines.com
A Performance Cheat Sheet for PostgreSQL
1–10 of 15 posts
Re: A Performance Cheat Sheet for PostgreSQL
#2Re: A Performance Cheat Sheet for PostgreSQL
#3Re: A Performance Cheat Sheet for PostgreSQL
#4Re: A Performance Cheat Sheet for PostgreSQL
#5Re: A Performance Cheat Sheet for PostgreSQL
#6Does anyone have a direct link without signing up? Just put your logo in the pdf, brand it, but I'm not gonna sign up just to get spammed with advertising.
Re: A Performance Cheat Sheet for PostgreSQL
#7Does anyone have similar references for doing 0-downtime migrations? For example, building your indexes with CONCURRENTLY to prevent table locking.
Re: A Performance Cheat Sheet for PostgreSQL
#8Nice reference! Does anyone have similar references for doing 0-downtime migrations? For example, building your indexes with CONCURRENTLY to prevent table locking.
Re: A Performance Cheat Sheet for PostgreSQL
#9Nice reference! Does anyone have similar references for doing 0-downtime migrations? For example, building your indexes with CONCURRENTLY to prevent table locking.
Even if you aren't on Rails or don't want to use the gem, it is still nice a checklist.
Re: A Performance Cheat Sheet for PostgreSQL
#10This strikes me as a generalization that is, at best, questionable. (Also, these days, with spinning disks, I'd more likely do RAID6, but I expect it's comparable enough).
I'd tend to agree that, historically, it's been true, and is demonstrably true for certain situations, such as a read-heavy load or recovering from a failed disk.
However, is it really still true for modern RAID cards?
What about with SSDs? I'd expect that cost is still a significant consideration for anyone specifying hardware, making the difference between RAID5 and RAID10 important.