> A really nice thing about code written from the 90s and earlier is that it was designed from the get go to be perfomant, because it had to be. I don't think

> A really nice thing about code written from the 90s and earlier is that it was designed from the get go to be perfomant, because it had to be. I don't think that's really the case in PG. Sure there's some places like that, but there were a lot of fairly fundamental performance issues only fixed in the last year. And there's still a lot of things to be done. Additionally a lot things that you had to do 20+ years ago, aren't the ones that you have to do today to get good performance. Being careful about cache usage and pipeline stalls became a lot more important on recent-ish CPUs than earlier ones. > No one in conventional sw writes code like that anymore, not really. eg. When was the last time you used a profiler? I think that's more a difference between application and infrastructure pieces of code. It's only worth spending time (and have skilled enough people) doing detailed optimization work if $project is going to be in the bottleneck for a lot of people. A couple of days on postgres can result in a lot bigger savings, if you multiply the saved optimization time over all its users.