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

Steve Yeom commented on HIVE-19975:
-----------------------------------

[~sershe] has added test case for partition here: 
"
Consider two scenarios:
1) Serially, with no parallel txns:
Write ID 1 inserts into partition k=1, partition stats table in metastore has 
valid write ID list is (1).
Reader tries to read, table’s valid write ID list is (1), partition k=1 list in 
stats table is (1), they are equivalent, all good.
Write ID 2 inserts into partition k=2, partition stats  table in metastore has 
valid write ID  list is (1,2).
Reader tries to read, table’s valid write ID list is (1,2). For partition k=2, 
the list is (1,2), equivalent returns true, all good. But for partition k=1, 
the list is still (1), because writer 2 doesn’t touch it. Equivalent returns 
false, stats cannot be used.
"
My answer to this test case scenarios is 
For #1, I have already simulated all the possible cases regarding reader’s 
starting point in time. It should work with the current patch.
 

> Checking writeIdList per table may not check the commit level of a partition 
> on a partitioned table.
> ----------------------------------------------------------------------------------------------------
>
>                 Key: HIVE-19975
>                 URL: https://issues.apache.org/jira/browse/HIVE-19975
>             Project: Hive
>          Issue Type: Sub-task
>          Components: Transactions
>    Affects Versions: 4.0.0
>            Reporter: Steve Yeom
>            Assignee: Sergey Shelukhin
>            Priority: Major
>             Fix For: 4.0.0
>
>
> writeIdList is per table entity but stats for a partitioned table are per 
> partition. 
> I.e., each record in PARTITIONS has an independent stats. 
> So if we check the validity of a partition's stats, we need to check in the 
> context of 
> a partiton. 



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

Reply via email to