Sergey Shelukhin commented on HIVE-19416:

Wouldn't 1.1 case be also detected by 1.2, assuming these two 
checks/alterations of tables are safe for races? I guess one case could be when 
table data is affected without creating a txn, so txn state cannot be 
recorded... however, if such changes exist (I'm not sure they do) how are they 
protected from races? is it by ACID locks? Just checking.
If my assumptions are correct (alter doesn't create txn/writeId but is safe due 
to locks), it might be cleaner for txn tables to not have the parameter stored, 
but instead just unset the txnId/writeIds data. If it's unset it will never 
match any query, which is the intention. The parameter can just be generated at 
read time, and not exist in DB.
3.1-2 I don't think anybody's working on that. If stats optimizer gets write 
IDs but then some in-flight txn commits before Driver gets locks and writeIds, 
it could mean stats optimizer picks different data than the actual query would 
pick. So that is a problem.

> Create single version transactional table metastore statistics for 
> aggregation queries
> --------------------------------------------------------------------------------------
>                 Key: HIVE-19416
>                 URL: https://issues.apache.org/jira/browse/HIVE-19416
>             Project: Hive
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Steve Yeom
>            Assignee: Steve Yeom
>            Priority: Major
> The system should use only statistics for aggregation queries like count on 
> transactional tables.

This message was sent by Atlassian JIRA

Reply via email to