By: Gabriele Svelto (gabriele.svelto.delete@this.gmail.com),
Room: Moderated Discussions
Anon (no.delete@this.spam.com) on February 3, 2020 1:34 am wrote:
> Google for "MySQL OOM", "MySQL memory overcommit", etc and you will find what
> you want, but MySQL/MariaDB are not in the same class of other RDBMSes.
Doesn't mean they're not databases. What about no SQL databases? Do these count too or not? "All databases do that" is a bold claim once you realize that the vast majority don't, and even the remaining ones do only some of the time.
> Although subjective, it is very simple to separate MySQL/MariaDB from real databases, in a real database
> you can query your data in efficient ways, with simple and readable text, at least most of the time, and
> the software will choose an appropriate algorithm to the task, will try to make data access faster, will
> try to make good use of resources, make manipulation of data consistent, PostgreSQL, Oracle, SQL Server,
> DB2, Sybase, all does this, MySQL/MariaDB implements a trivial set of algorithms to look like a database.
You don't get to pick what is a database and what isn't after making a broad statement about how "databases" handle memory.
> The user MAY tune the server for his specific need, don't HAVE
> to and documentation suggest he SHOULD NOT, so what?
It wasn't me who made a sweeping statemenet about databases handle memory. It was you, now you have to prove it.
> > 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.
>
> SQL Server In-Memory OLTP
>
> Did you notice the "In-Memory" expression when linking?
Yes, did you notice that I explicitly noted it was one type of setup? Funny how it can't check for memory allocations all the time under all conditions.
> I never looked at SQL Server source code, but I guess there is no malloc at all,
> also I am pretty sure that there are checks at all calls to VirtualAlloc.
ROFLMAO.
> Google for "MySQL OOM", "MySQL memory overcommit", etc and you will find what
> you want, but MySQL/MariaDB are not in the same class of other RDBMSes.
Doesn't mean they're not databases. What about no SQL databases? Do these count too or not? "All databases do that" is a bold claim once you realize that the vast majority don't, and even the remaining ones do only some of the time.
> Although subjective, it is very simple to separate MySQL/MariaDB from real databases, in a real database
> you can query your data in efficient ways, with simple and readable text, at least most of the time, and
> the software will choose an appropriate algorithm to the task, will try to make data access faster, will
> try to make good use of resources, make manipulation of data consistent, PostgreSQL, Oracle, SQL Server,
> DB2, Sybase, all does this, MySQL/MariaDB implements a trivial set of algorithms to look like a database.
You don't get to pick what is a database and what isn't after making a broad statement about how "databases" handle memory.
> The user MAY tune the server for his specific need, don't HAVE
> to and documentation suggest he SHOULD NOT, so what?
It wasn't me who made a sweeping statemenet about databases handle memory. It was you, now you have to prove it.
> > 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.
>
> SQL Server In-Memory OLTP
>
> Did you notice the "In-Memory" expression when linking?
Yes, did you notice that I explicitly noted it was one type of setup? Funny how it can't check for memory allocations all the time under all conditions.
> I never looked at SQL Server source code, but I guess there is no malloc at all,
> also I am pretty sure that there are checks at all calls to VirtualAlloc.
ROFLMAO.
