phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas D'Silva (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-3534) Support multi region SYSTEM.CATALOG table
Date Thu, 03 May 2018 19:07:00 GMT


Thomas D'Silva commented on PHOENIX-3534:


Currently if you change a table property on a base table that is valid on a view we propagate
it to all child views. If the table property is not mutable on the child view we set it to
the parent view value. If it is mutable and the view didn't change the property we set it
to the parent view value. 

After splittable system catalog since we resolve the parent hierarchy of a view while combining
columns we can also inherit the table properties from the base table. If a table property
is valid on a view but not mutable on a view we can just use the base table value. If it is
mutable on a view, we don't know if the property was changed on the view on not, so we have
to use the value that is set on the view. 

This is different from the existing behavior, where if you change a table property that is
valid on a view and mutable on view and if it wasn't changed on the view, it would get propagated
to all the child views. Is this ok?

> Support multi region SYSTEM.CATALOG table
> -----------------------------------------
>                 Key: PHOENIX-3534
>                 URL:
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: Thomas D'Silva
>            Priority: Major
>         Attachments: PHOENIX-3534-wip.patch
> Currently Phoenix requires that the SYSTEM.CATALOG table is single region based on the
server-side row locks being held for operations that impact a table and all of it's views.
For example, adding/removing a column from a base table pushes this change to all views.
> As an alternative to making the SYSTEM.CATALOG transactional (PHOENIX-2431), when a new
table is created we can do a lazy cleanup  of any rows that may be left over from a failed
DDL call (kudos to [~lhofhansl] for coming up with this idea). To implement this efficiently,
we'd need to also do PHOENIX-2051 so that we can efficiently find derived views.
> The implementation would rely on an optimistic concurrency model based on checking our
sequence numbers for each table/view before/after updating. Each table/view row would be individually
locked for their change (metadata for a view or table cannot span regions due to our split
policy), with the sequence number being incremented under lock and then returned to the client.

This message was sent by Atlassian JIRA

View raw message