ramitg254 commented on PR #6089: URL: https://github.com/apache/hive/pull/6089#issuecomment-3547579033
Hi, I ran a script which executes the queries of pattern cbo_* and query* under perf directory with `-Dhive.stats.fetch.bitvector=false` and with the postgres dump the overall time elapsed results were like below: <img width="304" height="183" alt="Screenshot 2025-11-18 at 6 23 06 PM" src="https://github.com/user-attachments/assets/0a577bdd-c4b7-49a7-9ddf-26ce35ca5343" /> and since there is significant gap in overall time elapsed to execute all the queries and also results of some queries varies after the drop of `aggrStatsUseDB` in case of `-Dhive.stats.fetch.bitvector=false`. Considering this performance drop and varied results I don't think we should go ahead with dropping of `aggrStatsUseDB`. Since currently that's the case so I have raised this current patch which addresses my original concern of handling the behaviour of merging in case of direct sql batch size defined and in this patch I am just adding merging logic which and no change in the earlier behaviour so there won't be any performance issues as well but similar like I tested it out with same set of queries and config and results which I saved earlier originally get generated via `aggrStatsUseDB` didn't change with this logic as well and their time elapsed results are somewhat like this: <img width="305" height="182" alt="Screenshot 2025-11-18 at 6 36 57 PM" src="https://github.com/user-attachments/assets/7241c86b-08a6-406f-b589-87e7b8be0ceb" /> @dengzhhu653 @deniskuzZ @kasakrisz @saihemanth-cloudera please share your thoughts on this -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
