phoenix-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoffrey Jacoby (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-5138) ViewIndexId sequences created after PHOENIX-5132 shouldn't collide with ones created before it
Date Tue, 05 Mar 2019 19:20:00 GMT

    [ 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)

Mime
View raw message