Is `parquet_inflation_factor` still respected in f...
# general
g
Is
parquet_inflation_factor
still respected in flotilla? I have a parquet file that is ~2GB, but expands to ~16GB in memory. When trying to run a select with window function, it is trying to load all data into memory and struggling (OOMing). What is the best course of action here?
āœ… 1
my only thought is to rewrite into smaller/more parquet files via config.
into_partitions
and
repartition
have similar issues
Copy code
daft.context.set_execution_config(
    parquet_inflation_factor=10,
    scan_tasks_min_size_bytes=int(1 * 1024 * 1024),
    parquet_target_filesize=int(64 * 1024 * 1024),
    parquet_target_row_group_size=int(16 * 1024 * 1024),
)
Copy code
testing = (
    daft.read_parquet("~/Desktop/some_data")
    .select(
        "date",
        "id",
        row_number()
        .over(
            Window()
            .partition_by(
                daft.col("date"),
                daft.col("id"),
            )
            .order_by(daft.col("some_col"), desc=[True])
        )
        .alias("rn"),
    )
    .where(daft.col("rn") == daft.lit(1))
    .exclude("rn")
)
m
cc @Colin Ho or @Srinivas Lade to investigate (please šŸ™)
c
Hmmmm unfortunately right now the window functions fully materialize all the data per partition. On flotilla, we should be able to alleviate this by specifying a repartition before the window. But I'll need to add a fix in for that real quick
šŸ™ 1
šŸ’” 1
Also to answer your other question • Is
parquet_inflation_factor
still respected in flotilla: Yes, it is respected on a per partition basis
@Srinivas Lade https://github.com/Eventual-Inc/Daft/pull/5450 pls help review tks
šŸ‘ 1
g
Hmmmm unfortunately right now the window functions fully materialize all the data per partition.
got it, I think this makes sense....so right now it is treating that whole parquet file as a single partition?
c
yeah thats right