Anon (no.delete@this.spam.com) on February 2, 2020 9:15 pm wrote:
> So you started by looking first by the crapware I mentioned earlier
> (MySQL/MariaDB)... I won't even comment on this fake DBMS.

I see that you were wrong about the most used DB in existence and you hand-wave it away because it doesn't fit your narrative.

> About others, it is true they all have several tunable options which the user MAY (not HAS) set
> to tune for their specific case, in the case of PostgreSQL, let them talk about themselves:
> In Linux 2.4 and later, the default virtual memory behavior is not optimal for PostgreSQL.
> Because of the way that the kernel implements memory overcommit, the kernel might terminate
> the PostgreSQL postmaster (the master server process) if the memory demands of either
> PostgreSQL or another process cause the system to run out of virtual memory.
> https://www.postgresql.org/docs/current/kernel-resources.html
>
> Oracle recommends disabling memory overcommit as well, Microsoft set a configurable
> limit on SQL on Linux that default to 80%, on Windows the user may specify a limit,
> the default is to use as much as needed without causing a crash.
>
> Also, it is common for databases to use compressed storage, not just Oracle, and
> what? Reading a header with the uncompressed size allow it to be predictable.
>
> But there are queries where the memory usage is really unpredictable, yet, databases do their best to ESTIMATE
> memory usage, if the actual memory usage is higher than the estimate the engine may offload the work to disk,
> and of course, without a crash, after all, the dataset of a database is expected to not fit in memory.
>
> BTW, they estimate by storing statistics about the data, for Oracle:
> https://docs.oracle.com/database/121/CCAPP/GUID-E4F013A8-E83C-44AF-B9A4-CA1FBF717730.htm#CCAPP9634
>
> [...]
>
> Every real DBMS does that.

First of all you don't get to pick which one is a "real" database and which one is not in order to prove your point. The all are.

Secondly the amount of configuration options shown in the links you posted seems to contradict this claim. Even Microsoft's SQL server requires explicit configuration to avoid out-of-memory conditions in certain modes. That's particularly ironic because the documentation goes to great lengths to claim that in regular mode it shouldn't need any kind of setup and will automatically scale memory usage up and down on demand.

Funny thing also: SQL server doesn't detect low memory conditions because you start getting NULL's from malloc() calls, it uses memory resource notifications.