pub struct MergeSpec { /* private fields */ }Expand description
A merge operation: several tables into one, with no user job.
What a sort does for order, a merge does for chunk layout — and in
MergeMode::Sorted it is the cheap way to combine tables that are already
sorted, because nothing has to be sorted again.
use ytsaurus_client::{MergeMode, MergeSpec};
let spec = MergeSpec::new(["//tmp/monday", "//tmp/tuesday"], "//tmp/week")
.with_mode(MergeMode::Sorted)
.with_merge_by(["host"]);Implementations§
Source§impl MergeSpec
impl MergeSpec
Sourcepub fn new<I>(inputs: I, output: impl Into<String>) -> Self
pub fn new<I>(inputs: I, output: impl Into<String>) -> Self
Merges inputs into output, unordered.
Sourcepub fn with_merge_by<K>(self, columns: K) -> Self
pub fn with_merge_by<K>(self, columns: K) -> Self
The columns a MergeMode::Sorted merge merges by.
The output table comes back sorted by these. Optional: a sorted merge sent without it is accepted, and the cluster uses the sort columns the inputs already have. Naming them is how to merge by a prefix of that, and how to make the assumption visible where it is being made.
Sourcepub fn with_combine_chunks(self, combine: bool) -> Self
pub fn with_combine_chunks(self, combine: bool) -> Self
Asks the cluster to combine small chunks while it merges.
This is most of why a merge is worth running on one table: a table written in many small pieces reads faster afterwards.
Sourcepub fn with_force_transform(self, force: bool) -> Self
pub fn with_force_transform(self, force: bool) -> Self
Runs the jobs even when the merge could be done by moving chunks.
A merge that has nothing to do normally just relinks chunks. Set this when the point is the rewrite — a change of compression codec or erasure coding, which only happens where rows are actually copied.
Sourcepub fn with_job_count(self, count: i64) -> Self
pub fn with_job_count(self, count: i64) -> Self
Asks for a particular number of jobs.
Takes precedence over data_size_per_job, which the cluster otherwise
uses to decide.