Skip to content

config,kvserver: don't unconditionally split on table boundaries for the host tenant #66063

@irfansharif

Description

@irfansharif

Is your feature request related to a problem? Please describe.

On the host tenant, we unconditionally split on all table/index/partition boundaries. There are two reasons this might have been desirable:
(a) Performance: splitting off each table/index/partition into its own range guarantees independent range processing of the data within that table/index/partition.
(b) Diverging zone configs: if two tables have different zone configs attached to them (remember: the "unit" of what a zone config can apply to is a db/table/index/partition), that necessarily implies a split. By unconditionally splitting on table boundaries, we didn't have to write code to reason about adjacent-keys-but-from-different-tables-with-diverging-zone-configs.

Describe the solution you'd like

For (a) we could support syntax for users to specify intentional split on table boundaries #65903. For (b), we're soon going to introduce zone configs for secondary tenants. By default we don't split on table boundaries for secondary tenants due to the order-of-magnitude ranges that would create, but with secondary tenant zone configs, we're opening the door to tenant-initiated splits in the tenant keyspace. That means we're going to write code that reasons about adjacent-keys-but-from-different-tables-with-diverging-zone-configs, to determine where the necessary split points would be, so we may as well coalesce host tenant tables into single ranges when possible. If secondary indexes or groups of tables are placed on the same range, txns that span them could benefit from 1PC optimizations.

Describe alternatives you've considered

Keeping the status quo. I think this issue only really matters for on-prem customers (without multi-tenancy) where each table would today create a new range. For users with many small tables, the overhead of the very many tiny ranges might be undesirable. With tenant zone configs we'll soon be addressing the O(descriptors) bottleneck that today prevent having too many tables. Perhaps it's time to look ahead.

Jira issue: CRDB-7866

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-kv-distributionRelating to rebalancing and leasing.A-zone-configsC-enhancementSolution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions