I wrote some hints on how to optimise #SQL queries containing LIKE. More ideas, including unconventional ones, are very welcome - just comment here or on the website.

This is a great explanation! I wonder many times why we had to play with obscure xargs instead of being able to pipe a command output to an argument.

The problem, though, is that SQL standard treats NULL as unknown or as missing. One word for two meanings.

For example, AVG(col) and COUNT(col) treat it as a missing value (NULLs do not alter the average or the count), but 1 + NULL treats it as an unknown value (the result is unknown). The complete list of NULL-related inconsistencies would be long.

It would have been better to use different words for different semantics, or not implementing NULL at all. Also, in some cases it can lead to poor query performance.

I emphatically reject the idea that having an imperfect null is worse than no null at all, but I understand frustrated programmers may have different beliefs.

You are right, though (some?) DBMSs allow to use HAVING for columns that appear in the GROUP BY clause.

You are correct, HAVING is essentially syntax sugar. But to be fair, I'm glad it exists.

Sure, and I remember the version of mySQL that didn't have sub-queries. Having HAVING has your back, then.

Still work in progress and the topics are not too in-depth... but it's interesting, thanks.

Fantastic videos! Thanks for the links!

Yes, Kubernetes uses cgroup too.

Systemd units are also based on cgroups.