Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/281#discussion_r153594426
--- Diff:
phoenix-core/src/it/java/org/apache/phoenix/end2end/CostBasedDecisionIT.java ---
@@ -0,0 +1,171 @@
+package org.apache.phoenix.end2end;
+
+import static org.apache.phoenix.util.TestUtil.TEST_PROPERTIES;
+import static org.junit.Assert.assertTrue;
+
+import java.sql.Connection;
+import java.sql.DriverManager;
+import java.sql.PreparedStatement;
+import java.sql.ResultSet;
+import java.util.Map;
+import java.util.Properties;
+
+import org.apache.phoenix.query.BaseTest;
+import org.apache.phoenix.query.QueryServices;
+import org.apache.phoenix.util.PropertiesUtil;
+import org.apache.phoenix.util.QueryUtil;
+import org.apache.phoenix.util.ReadOnlyProps;
+import org.junit.AfterClass;
+import org.junit.BeforeClass;
+import org.junit.Test;
+
+import com.google.common.collect.Maps;
+
+public class CostBasedDecisionIT extends BaseUniqueNamesOwnClusterIT {
--- End diff --
3 tests is better than 1, but more would be better. Here are some ideas:
- test that DELETE is optimized through cost-based as expected
- same for UPSERT SELECT
- how about a UNION query?
- same for some join queries
- how about a case where one plan would have a filter on a single leading
column while another would have a filter on the first two leading columns, but
the former plan would scan less data. In theory, the cost-based approach would
choose the former.
---
