You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@phoenix.apache.org by "Geoffrey Jacoby (JIRA)" <ji...@apache.org> on 2019/03/05 19:20:00 UTC

[jira] [Commented] (PHOENIX-5138) ViewIndexId sequences created after PHOENIX-5132 shouldn't collide with ones created before it

    [ https://issues.apache.org/jira/browse/PHOENIX-5138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16784807#comment-16784807 ] 

Geoffrey Jacoby commented on PHOENIX-5138:
------------------------------------------

[~tdsilva] - Is there a way to easily tell the ViewIndexTypeId of a given row in an _IDX_ table? Because there's a nice O(1) way to get a row with the max ViewIndexId -- just do a reverse Scan and take the first row returned, since the _IDX_ tables are sorted by ViewIndexId. But since a ViewIndexId can be one of several numeric types, I'm not sure there's a good O(1) to _interpret_ the bytes I'd get back. 

I can figure out the max ViewIndexId by querying syscat: 

Select max(viewindexid) from system.catalog where table_type = 'i' and table_name in (select table_name from system.catalog where Link_Type = 2 and Column_Family = '<name of idx table>')

But both the inner query and the outer query will require table scans on System.Catalog so will have poor performance in just the kind of environments with many views that this JIRA's meant to help. 

> ViewIndexId sequences created after PHOENIX-5132 shouldn't collide with ones created before it
> ----------------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-5138
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-5138
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.15.0
>            Reporter: Geoffrey Jacoby
>            Assignee: Geoffrey Jacoby
>            Priority: Major
>
> PHOENIX-5132 changed the ViewIndexId generation logic to use one sequence per physical view index table, whereas before it had been tenant + physical table. This removed the possibility of a tenant view index and a global view index having colliding ViewIndexIds.
> However, existing Phoenix environments may have already created tenant-owned view index ids using the old sequence, and under PHOENIX-5132 if they create another, its ViewIndexId will got back to MIN_VALUE, which could cause a collision with an existing view index id. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)