/** * Parallel Parquet generation (`--jobs N`). * * The text coordinator splits rows; this one splits ROW GROUPS. That is the * whole trick: a group's bytes are position-independent (page headers carry * sizes, and every offset in the format lives in the footer), so workers can * build whole groups on their own and the coordinator only has to lay them end * to end, shift the recorded offsets, and write one footer. * * Splitting on a group boundary rather than an arbitrary row is what keeps the * output byte-identical to a single-threaded run: cut mid-group and the file * would contain groups a `--jobs 1` run never produces. * * Measured motivation: a 1M-row config spends ~7s of CPU but only ~1.1 cores, * because Parquet was excluded from `--jobs`. The same work spread over the * cores the text path already uses brings the wall clock down accordingly. */ export interface ParquetParallelParams { readonly source: string; readonly seed: string; readonly count: number; /** An override the caller asked for — never a default, or it beats the config's `local=`. */ readonly locale: string | undefined; /** The project config's locale: a fallback for a config that names none. */ readonly defaultLocale?: string | undefined; readonly now: number; readonly dataPaths?: readonly string[] | undefined; readonly baseDir?: string | undefined; readonly jobs: number; readonly destFd: number; /** * Called as the run advances, with the WHOLE file's numbers. * * Same reason as the text path: above a hundred thousand rows the command * line splits the run by itself, so a channel that only worked on one thread * was silent exactly when somebody needed it. */ readonly onProgress?: ((progress: { phase: 'uniq-scan' | 'uniq-sort' | 'uniq-repair' | 'render'; done: number; total: number; }) => void) | undefined; } export { parquetJobLimit } from './parallel-plan.js'; /** Generate to `destFd` across worker threads. */ export declare function runParquetParallel(params: ParquetParallelParams): Promise; //# sourceMappingURL=parquet-parallel.d.ts.map