[
https://issues.apache.org/jira/browse/PHOENIX-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13900861#comment-13900861
]
James Taylor commented on PHOENIX-21:
-------------------------------------
Thinking about this a bit more, I think it's best to just create the physical
index table under-the-covers. We can provide a new property to define the
MAX_FILE_SIZE of the index table as a percentage of the MAX_FILE_SIZE of the
data table.
One other thing I realized is that I don't need to include the constant values
from the view definition in the index at all. I'll just replace their
occurrence in the query that gets generated for the index plan with the
constant value. That simplifies things a bit and will make the index smaller
too which is good.
> Support indexes on multi-tenant views
> -------------------------------------
>
> Key: PHOENIX-21
> URL: https://issues.apache.org/jira/browse/PHOENIX-21
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: James Taylor
>
> Current plan is to create a sibling index table based on the base
> multi-tenant table, suffixed with _INDEX when the base table is created. If
> your interested in this feature, best to review the following documents first:
> http://phoenix.incubator.apache.org/views.html
> http://phoenix.incubator.apache.org/multi-tenancy.html
> In addition, we need a multi-tenant sequence, again based on the multi-tenant
> table name suffixed with _SEQ. The base columns in this table would be: the
> first column from the base table (i.e. the tenant ID column) followed by
> index id SMALLINT. This index ID is required to ensure that data from
> different indexes on the same multi-tenant table don't intermix with each
> other (as the rest of the PK is specific to the index being added). The index
> ID would be based on the next value in the _SEQ (a multi-tenant sequence).
> For simplicity, make it two bytes, starting with Short.MIN_VALUE. We'll never
> reuse an ID, so this gives us 64K create/drop indexes per multi-tenant base
> table. The rest of the PK columns would depend on the index being created,
> and would include in this order:
> <any constant columns (think key-prefix here) from your updatable view>
> <the indexed columns from the create index statement>
> <the rest of the PK columns from the data table - standard logic here>
> The changes necessary to support this include:
> 1. Tracking the constant value referenced on a column for an updatable view
> in PColumn. Might as well track if a column is referenced by a view as well.
> Two new columns: IS_REFERENCED_BY_VIEW, CONSTANT_VALUE_IN_VIEW. For the IS
> NULL case, we can use an empty byte array to differentiate from a null. These
> values would be passed through the CreateTableCompiler and upserted with the
> rest of the data.
> 2. Disallow the removal of any column in a view that is referenced in the
> view statement. An alternative would be to invalidate the view.
> 3. Add a new INDEX_ID column to PTable specifically for an INDEX on a VIEW.
> This will get populated based on the next value in the sequence.
> 4. Push the CONSTANT_VALUE_IN_VIEW into the IndexMaintainer along with the
> tenantId and the index ID. These values will be used to form the Put(s) and
> Delete(s) that get formed when an index is maintained.
> 5. Modify the code that automatically prepends tenant_id to also prepend the
> index ID in the case. This will be in WhereOptimizer, UpsertCompiler, and
> DeleteCompiler.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
