Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sql: disable gossip-based physical planning by default #135034

Merged
merged 1 commit into from
Nov 25, 2024

Commits on Nov 23, 2024

  1. sql: disable gossip-based physical planning by default

    Now that we improved handling of draining procedure in the virtual
    clusters in 24.3 timeframe, I believe it's time to begin fully
    deprecating the gossip-based physical planning, and as the first step
    this commit introduces a cluster setting to control which method is used
    in single-tenant deployments (instance-based planning being the
    default). I plan to have the setting as an escape hatch in case we find
    problems when rolling out this change and to remove the setting
    altogether after 25.2.
    
    One of the differences between two planning methods is slightly adjusted
    in this commit. In particular, in the instance-based planning we stitch
    together consecutive spans whenever `EnsureSafeSplitKey` for the keys in
    the spans returns the same prefix. The idea is that spans corresponding
    to different column families of the same SQL row must be placed on the
    same instance. However, the condition on the length of the keys returned
    by `EnsureSafeSplitKey` is too broad and captures more cases than
    needed (i.e. two keys that cannot be part of the same SQL row end up in
    the same `SpanPartition`). To partially alleviate this difference, this
    commit introduces "boundary granularity" knob which indicates whether
    consecutive spans _might_ be part of the same SQL row, and we now use
    the stitching logic only if so. All callers of `PartitionSpans` have
    been audited, and we need the stitching logic only in two call sites that
    correspond to planning of table readers. Longer term, if we change the
    encoding so that column family IDs are encoded in a special way, we'll
    be able to tell definitively whether stitching is needed simply based on
    the key itself, and this additional logic could be removed.
    
    Epic: None
    
    Release note: None
    yuzefovich committed Nov 23, 2024
    Configuration menu
    Copy the full SHA
    5507067 View commit details
    Browse the repository at this point in the history