Devs who don't understand how SQL or relational databases work write absolute abortions of queries.
9 times out of 10 - yes it is absolutely the devs. I say that as the dev who gets tasked with analysing why these shitty queries from our low budget outsourced labour are so slow
"Hmm since I don't feel like looking in the documentation for every possible key of this attribute, I'll just throw a distinct. And while I'm at it, let's do this for every attribute that I don't know the keys of"
I feel like the popularity of the LAMP stack (or WAMP if you were just starting out your interest in software and hadn't yet moved to Linux) in the 00s and early 10s is to blame here. MySQL ended up being the default choice for people who didn't know much about databases.
Now that I know more than I did at the age of 14 when I first started learning programming... I'll be honest, I'm still likely to choose MySQL just because it's familiar. But at least I know what indices are now, and I try to avoid dependent subqueries :)
To be fair, I feel like I should use Postgresql more, I just haven't actually ever worked on anything that needed the cool data types it has extensions for.
Databases need tuning for your workload, and most people just think it’s a big box where you can dump anything you want and it will work. And then when it chokes on a terrible query they blame the DBA.
Could be an instance of BSD where (so I hear) PIDs are assigned randomly from the unused numbers, or else the system has massive process churn going on elsewhere and the old timer is from a previous cycle of consecutive PIDs.
Some systems still have /proc/sys/kernel/pid_max set to something around 32768, so wrapping back to 0 can happen fairly often.
Given all the PIDs in the comic seem pretty low, it might even be as low as 1024 wherever this is.
@Bye@devilish666 file systems are a good replacement for a database for many use cases. however: some file systems are bad at handling many small files. also databases can do indexes, which file-systems can't: they are key-value stores