[
https://issues.apache.org/jira/browse/HIVE-19416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510455#comment-16510455
]
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
(v7.6.3#76005)
