Jesus Camacho Rodriguez commented on HIVE-18825:

bq. Just because some feature doesn't exist yet, it doesn't mean we should make 
changes that will make that feature impossible in the future.

I agree with your statement, but I disagree that this change makes the feature 
impossible. The proposal is to split the work in two steps. When we implement 
concurrency based lock control (or we can do it even before that), we will need 
to move the lock acquisition logic before query compilation as part of that 
feature work.

> Define ValidTxnList before starting query optimization
> ------------------------------------------------------
>                 Key: HIVE-18825
>                 URL: https://issues.apache.org/jira/browse/HIVE-18825
>             Project: Hive
>          Issue Type: Improvement
>          Components: Transactions
>    Affects Versions: 3.0.0
>            Reporter: Jesus Camacho Rodriguez
>            Assignee: Jesus Camacho Rodriguez
>            Priority: Major
>         Attachments: HIVE-18825.01.patch, HIVE-18825.02.patch, 
> HIVE-18825.03.patch, HIVE-18825.04.patch, HIVE-18825.patch
> Consider a set of tables used by a materialized view where inserts happened 
> after the materialization was created. To compute incremental view 
> maintenance, we need to be able to filter only new rows from those base 
> tables. That can be done by inserting a filter operator with condition e.g. 
> {{ROW\_\_ID.transactionId < highwatermark and ROW\_\_ID.transactionId NOT 
> IN(<open txns>)}} on top of the MVs query definition and triggering the 
> rewriting (which should in turn produce a partial rewriting). However, to do 
> that, we need to have a value for {{ValidTxnList}} during query compilation 
> so we know the snapshot that we are querying.
> This patch aims to generate {{ValidTxnList}} before query optimization. There 
> should not be any visible changes for end user.

This message was sent by Atlassian JIRA

Reply via email to