Skip to content

Optimizer registration ordering is error prone #3131

Description

@jzelinskie

Problem Statement

When registering new query planner optimizers, you currently provide a priority as a number; this number resolves the order in which the optimizers run.

As the number of optimizers grow, it becomes very difficult to compute the total ordering of the registered optimizers or make changes to their order.

This issue was first raised here: #3051 (comment)

Solution Brainstorm

There are a variety of solutions that could help here with various trade-offs:

  • Developer tooling to compute and print the optimizer orderings
  • Consolidate registration into one place where the code reads as ordered list, similar to registering gRPC middleware
  • Replace priority number with "before" and "after" fields that resolve order similar to systemd unit files or our existing db migration tooling

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/proposalSomething fundamentally needs to changekind/tech debtAddresses legacy code/decisions

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions