neatHyperTxt-meesho opened a new pull request, #6785:
URL: https://github.com/apache/hive/pull/6785

   ### What changes were proposed in this pull request?
   Adds metastore.cached.rawstore.prewarm.threads (default 1 = current 
single-threaded behavior). With N > 1, prewarm fans the per-table work (table + 
partitions + statistics + constraints) out to N worker threads, each with its 
own RawStore instance — mirroring how CacheUpdateMasterWork creates its private 
store. Workers drain the existing TablesPendingPrewarm stack, so each table is 
handed out exactly once and the prioritizeTableForPrewarm hot-table promotion 
keeps working. The memory-full early stop uses a shared flag with 
completePrewarm called exactly once, and the worker pool plus worker stores are 
torn down when prewarm finishes. The per-table logic is extracted verbatim into 
prewarmTable(); the single-threaded path runs through the same code.
   
   ### Why are the changes needed?
   Prewarm is single-threaded and latency-bound: one thread issues ~6-8 
sequential queries per table. On our production deployment (Hive 4.2.0, 21k 
cached tables) prewarm takes ~10 minutes; with 8 threads it takes 195s vs 602s 
baseline (3.1x). Each worker uses one connection from the shared pool, so the 
config doc advises keeping the value below the pool size.
   
   ### Does this PR introduce _any_ user-facing change?
   A new optional config, metastore.cached.rawstore.prewarm.threads, default 1 
(no behavior change unless set).
   
   ### How was this patch tested?
   New unit test TestCachedStore#testPrewarmMultiThreaded runs a full prewarm 
with 4 threads against Derby and asserts every database, table and partition is 
cached. Full TestCachedStore suite passes (32/32). Benchmarked on a production 
deployment: 602s (1 thread) -> 195s (8 threads) for 21k tables.
   
   Once it's up, paste the link — and that's both contributions in flight.


-- 
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]

Reply via email to