You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reclaim prefetch promotion budget and reapply during iterative scaleup (#2590)
Summary:
Pull Request resolved: #2590
In D56505315 we promote tables that consume less HBM when not using
UVM_CACHING. This can happen when the input is large and the
overheads of calculating the uniques/populating the cache (around 7x
input size, or (1+6/12)x when using multi-pass prefetch, see
shard_estimators.py:calculate_pipeline_io_cost) dominate the saving
from having CLF < 1.0.
It runs the promotion both on the starting proposal (using
min-working-set), and after the proposed scaleup. In the second run,
because it runs after scaleup has completed, the saved memory is
"wasted".
In this diff, we integrate the promotion logic directly into the
interactive scaleup, so any memory saved via promotion is available to
further scale hard to cache tables. This can improve plan quality.
We still keep the original implementation to run on the initial
starting proposal. It's possible the starting proposal is not
partitionable with the configured storage reservation without this
initial promotion step. Removing this would cause the planner to fail
and never reach the scaleup.
The net result is that we'll try to use all of the probe budget,
rather undershooting, when tables have large I/O prefetch costs.
Reviewed By: keyan
Differential Revision: D66435139
fbshipit-source-id: 27faf36542266d323d5747280f4c1053b610cdc6
0 commit comments