Skip to content

*: optimize resolved-ts and checkpoint propagation latency #5705

Description

@asddongmen

Is your feature request related to a problem?

The TiCDC resolved-ts and checkpoint propagation path contains several avoidable periodic or next-notification waits. Even when upstream TiKV advances resolved-ts every 200 ms, batching and reporting intervals across LogPuller, EventService, DispatcherManager, and Maintainer can accumulate into noticeably higher changefeed latency.

Some dispatchers can also wait for the next EventStore notification when a scan is already running or when SchemaStore temporarily caps the scan frontier.

Describe the feature you would like

Provide an opt-in low-latency performance mode while keeping the current throughput-oriented behavior as the default.

The low-latency path should reduce unnecessary waits in resolved-ts advancement, dispatcher and Maintainer watermark reporting, checkpoint calculation, and scan continuation or schema-blocked recovery. Work must remain bounded and coalesced, with explicit CPU and control-message trade-offs.

Validate the design at large table and Region counts, covering steady-state latency, bootstrap, queue saturation, resource usage, and throughput-mode compatibility.

Prototype and initial scale-test results: asddongmen#4

Metadata

Metadata

Assignees

Labels

type/enhancementThe issue or PR belongs to an enhancement.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions