nuked my bad mysql eval
This commit is contained in:
parent
c8c7abf16c
commit
7f1c8cd01f
1 changed files with 0 additions and 13 deletions
|
@ -1853,19 +1853,6 @@ Such an optimization would be difficult to achieve with Berkeley DB
|
||||||
since the only diff-based mechanism it supports requires changes to
|
since the only diff-based mechanism it supports requires changes to
|
||||||
span contiguous regions of a record, which is not necessarily the case for arbitrary
|
span contiguous regions of a record, which is not necessarily the case for arbitrary
|
||||||
object updates.
|
object updates.
|
||||||
In a database server context, this type of optimization can be
|
|
||||||
supported if the fields of the object are broken into database table
|
|
||||||
columns. and a SQL update query only modifies a subset of the fields.
|
|
||||||
However, as we have seen in some preliminary evaluation,
|
|
||||||
the overheads associated with a SQL based interface outweigh the
|
|
||||||
advantages of this optimization. To avoid RPC costs, we ran the
|
|
||||||
benchmark using libmysqld, which bypasses RPC costs by linking MySQL
|
|
||||||
into an application binary. We used an InnoDB table, which seemed
|
|
||||||
to perform better than tables backed by Berkeley DB. Still, MySQL
|
|
||||||
was significantly slower then native Berkeley DB. If we do not link
|
|
||||||
the MySQL server into the application binary then the cost of local
|
|
||||||
interprocess communication dominates the test, causing the benchmark to
|
|
||||||
take too long to be reported here.
|
|
||||||
|
|
||||||
%% \footnote{It is unclear if
|
%% \footnote{It is unclear if
|
||||||
%% this optimization would outweigh the overheads associated with an SQL
|
%% this optimization would outweigh the overheads associated with an SQL
|
||||||
|
|
Loading…
Reference in a new issue