On 01.03.2018 16:30, Satyanarayana Narlapuram wrote:
Given transaction aborts are expensive, is there any impact on the crash
recovery?
In InnoDB/XtraDB, which has used the "move old row versions to UNDO log"
since the very beginning, rollbacks are indeed costly, and especially
so on recovery
On 27.04.2018 10:45, Mark Kirkwood wrote:
I note that Mysql (yeah I know, we don't love 'em greatly, but their
product niche is similar to ours) and Ceph (ok it is a distributed
storage system but still a highly popular open src product) have
switched to using cmake (relatively) recently. Both
On 28.04.2018 05:27, Yuriy Zhuravlev wrote:
"make distcheck"
CMake have no this bad concept, in my opinion, if you want to make the
project you should have a full build environment. (but I don't want to
argue about it here)
this is not about having a working build environment, it is abou
On 02.05.2018 16:22, Tom Lane wrote:
(-D? really?)
it's worse ... "cmake -L" only produces a alphabetically sorted list
of known -D settings, just listing the names without description.
That's so far behind from what
./configure --help
produces.
(And don't get me started on cmake-gui. On
On 02.05.2018 17:44, Robert Haas wrote:
But having parallel make work better and more efficiently
and with fewer hard-to-diagnose failure modes would definitely be
nice.
that's especially a thing I haven't seen in "our" environment,
this was an area where autotools and cmake didn't really diffe
ng PQC didn't provide that much of an improvement though,
and in the end I didn't bother to have to take care of yet
another service component in the setup.
--
Hartmut Holzgraefe, Principal Support Engineer (EMEA)
MariaDB Corporation | http://www.mariadb.com/
ng
outdated results back if they are not too old is OK.
--
Hartmut Holzgraefe, Principal Support Engineer (EMEA)
MariaDB Corporation | http://www.mariadb.com/
n the actual result values, too ...
--
Hartmut Holzgraefe, Principal Support Engineer (EMEA)
MariaDB Corporation | http://www.mariadb.com/
On 11.05.2018 14:26, Tatsuo Ishii wrote:
If any of the tables were
modified, cache entries using the table must be removed.
(these are already implemented in Pgpool-II's in memory query cache)
... and this is the expensive part in the MySQL implementation that
has rendered the query cache mostl
On 11.05.2018 18:01, Tatsuo Ishii wrote:
Plus checking username is neccessary (otherwise any user could
retrieve a cache for a table lookup which is not permitted by other
users).
as the tables a cached query operated on is known anyway -- it's needed
to purge cache entries when table content c
10 matches
Mail list logo
