Todd Lipcon has posted comments on this change.

Change subject: KUDU-1582. Optimize budgeted compaction policy with an 
approximation
......................................................................


Patch Set 2:

(9 comments)

http://gerrit.cloudera.org:8080/#/c/4153/2/src/kudu/tablet/CMakeLists.txt
File src/kudu/tablet/CMakeLists.txt:

Line 93: execute_process(COMMAND ln -sf 
${CMAKE_CURRENT_SOURCE_DIR}/ycsb-test-rowsets.tsv
> nit can you move this before the test (even if not needed makes more sense 
Done


http://gerrit.cloudera.org:8080/#/c/4153/2/src/kudu/tablet/compaction_policy-test.cc
File src/kudu/tablet/compaction_policy-test.cc:

Line 74:   CHECK_OK(ReadFileToString(Env::Default(), path, &data));
> add error message
Done


Line 79:     CHECK_EQ(3, fields.size()) << line;
> improve error message
Done


Line 82:                                         
ParseLeadingInt32Value(fields[0], -1) * 1024 * 1024));
> comment in this magic calculation?
Done


Line 88: TEST(TestCompactionPolicy, TestYcsbCompaction) {
> what is this really testing? just that we get better qualities with higher 
yea, both a benchmark and a kind of "realistic test", will add a comment to 
that effect


http://gerrit.cloudera.org:8080/#/c/4153/2/src/kudu/tablet/compaction_policy.cc
File src/kudu/tablet/compaction_policy.cc:

Line 46: DEFINE_double(compaction_approximation_ratio, 1.05f,
> would it be much harder to have this be 0 based? (i.e. 0.05 instead of 1.05
I think I'd rather stick with this since it's the definition usually used for 
approximation algorithms (see 
https://en.wikipedia.org/wiki/Approximation_algorithm#Performance_guarantees ).

Would it be clearer if I called it "approximation factor"?


PS2, Line 199: top
> nit: move this to the line above
Done


Line 247: // policy implementedin this function.
> missing space
Done


Line 311:   best_upper_bounds.reserve(asc_min_key.size());
> the reasoning seems good, but this is very dense, I wish there was a simple
I split into two methods, but not sure what an effective unit test would be. 
Any ideas? I could come up with some toy problem I suppose but verifying the 
actual test is pretty tough since you can't really run the dynamic program in 
your head.


-- 
To view, visit http://gerrit.cloudera.org:8080/4153
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I4e611f161d66ddc47e97e3b5328bc1778a4ac958
Gerrit-PatchSet: 2
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-Owner: Todd Lipcon <t...@apache.org>
Gerrit-Reviewer: Anonymous Coward #174
Gerrit-Reviewer: David Ribeiro Alves <dral...@apache.org>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Todd Lipcon <t...@apache.org>
Gerrit-HasComments: Yes

Reply via email to