Comments for domas mituzas

Comment on MySQL does not need SQL by markcallaghan (@markcallaghan)

markcallaghan (@markcallaghan) — Wed, 10 Aug 2016 17:46:50 +0000

This is server-side cursor logic and one example of that is the SQLite VM that lets you explain how to execute a SQL statement -> https://www.sqlite.org/vdbe.html

This isn’t server-side business logic, as provided by Tarantool with Lua and VoltDB with Java. I like both, but that is a different project.

I’d like to consider getting both into MySQL. Maybe FB MySQL will do it first.

Comment on MySQL does not need SQL by markcallaghan (@markcallaghan)

markcallaghan (@markcallaghan) — Thu, 04 Aug 2016 23:21:32 +0000

We should update this to indicate the number of index dives done by MyRocks. Regardless, I hope we get something to support some logic with fast/simple server side logic/cursors.

Comment on MySQL does not need SQL by Domas Mituzas

Domas Mituzas — Thu, 04 Aug 2016 03:17:21 +0000

In reply to Marc.

Though it may be better for some of our existing queries, there’s also a question how to improve queries if we can have better expressed conditional logic. Yoshinori is HandlerSocket expert, but he is busy with RocksDB now ;-)

Comment on MySQL does not need SQL by Marc

Marc — Wed, 03 Aug 2016 23:59:49 +0000

How do you feel about things like HandlerSocket (https://www.percona.com/doc/percona-server/5.6/performance/handlersocket.html)?
I guess it got removed in Percona 5.7, but for simple primary key access, it seemed interesting.
(Never looked very much into detail though)

Comment on linux memory management for servers by Nils Meyer

Nils Meyer — Fri, 13 May 2016 19:07:32 +0000

In reply to Domas Mituzas.

when was the last time the defaults for that setting were ever touched? I think this might warrant a bug report as well.

Comment on linux memory management for servers by Nils Meyer

Nils Meyer — Fri, 13 May 2016 19:06:26 +0000

I think we probably need something like there already is with block schedulers. Instead of finding an approach that fits every workload we can broadly define a certain workload and the memory allocation strategy that comes with it, while retaining a few knobs for fine tuning. The same can probably be said for process scheduling as well.

To be fair there is a lot of options exposed in procfs and sysfs, however the documentation leaves a lot to be desired and a lot of it has rarely been tested with standard parameters. I also think improving the handling of huge pages could be of some benefit.

Memory allocation will only get more complicated, since at some point it’s likely there’s going to be more layers as the lines between volatile and persistent storage are becoming more and more blurred – we already see this with CPUs adding L4 cache and with NAND coming as DIMM.

Comment on linux memory management for servers by chrone

chrone — Fri, 13 May 2016 18:41:53 +0000

In reply to Domas Mituzas.

I see, thanks for the heads up. :)

Comment on linux memory management for servers by Domas Mituzas

Domas Mituzas — Fri, 13 May 2016 18:39:50 +0000

In reply to chrone.

you need to accommodate your memory spikes – we are setting it to 1GB on various systems that have >100GB of RAM and have high memory spikes, 256-512MB is enough on many other.5% is an overkill, unless, of course, you’re on 16GB machine that has very high memory churn.

Comment on linux memory management for servers by chrone

chrone — Fri, 13 May 2016 18:37:03 +0000

So how big should we bump vm.min_free_kbytes? 5% of total memory? :)

Comment on on ORDER BY optimization by on ORDER BY optimization | Domas Mituzas | Open Query blog

on ORDER BY optimization | Domas Mituzas | Open Query blog — Sat, 01 Aug 2015 03:44:37 +0000

[…] https://dom.as/2015/07/30/on-order-by-optimization/ […]