kadirozde commented on code in PR #1531:
URL: https://github.com/apache/phoenix/pull/1531#discussion_r1072694727
##########
phoenix-core/src/it/java/org/apache/phoenix/end2end/index/UncoveredGlobalIndexRegionScannerIT.java:
##########
@@ -80,7 +93,39 @@ private void populateTable(String tableName) throws
Exception {
}
@Test
- public void testUncoveredIndexWithPhoenixRowTimestamp() throws Exception {
+ public void testDDL() throws Exception {
+ try (Connection conn = DriverManager.getConnection(getUrl())) {
+ String dataTableName = generateUniqueName();
+ String indexTableName = generateUniqueName();
+ conn.createStatement().execute("create table " + dataTableName +
+ " (id varchar(10) not null primary key, val1 varchar(10),
val2 varchar(10), val3 varchar(10))");
+ if (uncovered) {
+ // The INCLUDE clause should not be allowed
+ try {
+ conn.createStatement().execute("CREATE UNCOVERED INDEX " +
indexTableName
+ + " on " + dataTableName + " (val1) INCLUDE
(val2)");
+ Assert.fail();
+ } catch (Exception e) {
+ // Expected
+ }
+ // The LOCAL keyword should not be allowed with UNCOVERED
+ try {
+ conn.createStatement().execute("CREATE UNCOVERED LOCAL
INDEX " + indexTableName
Review Comment:
I defined an uncovered index as the index never covers a query. That means
the index rows are always joined with the data table rows (inner join). This
restriction allows optimizing the write path for index updates such that we can
update an uncovered index in one phase (instead of using two phase commit) and
do not need to retrieve data table rows when the data table mutations also
includes the index columns. Indexes before this feature are called (defined as)
covered indexes. A covered index can cover a query if all the referenced
columns are the columns of (i.e., covered by) the index table. A covered index
can be also used for queries that include uncovered columns, using index hints
whereas uncovered indexes do not require hints. The write path for local
indexes uses one phase update currently but the data table rows are read during
updates. In theory, we can introduce the uncovered local indexes to eliminate
the read operations during write transactions when mutations includ
e all index columns but we need to introduce index repair during read. I
suggest that we can reconsider this in future when the need arises. Please note
when we redesigned indexes we preserved the implementation of local indexes as
is since the old code was very difficult to crack. Adding changes for uncovered
local indexes would increase the complexity of this jira which is already
complex enough. Please let me know what you think about my reasoning.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
