fix: pre-warm listing file statistics cache during listing table creation by bharath-techie · Pull Request #18971 · apache/datafusion

bharath-techie · 2025-11-27T15:46:08Z

Pre-warm listing file statistics cache during create listing table flow as suggested in #18952.
Reused list_files_for_scan to pre-warm.

Which issue does this PR close?

Closes Bug: statistics not collected automatically upon creation of ListingTable #18952.

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Yes unit tested.

Are there any user-facing changes?

bharath-techie · 2025-11-27T15:50:32Z

datafusion/core/src/datasource/listing_table_factory.rs

+
+        // Pre-warm statistics cache if collect_statistics is enabled
+        if session_state.config().collect_statistics() {
+            let _ = table.list_files_for_scan(state, &[], None).await?;


Is it okay to reuse this method to pre-warm as we do couple more things post collecting the statistics ?

Also is no limit fine ? as list_file_statistics_cache doesn't seem to have any size limit unlike metadata cache ?

cc: @alamb

2. Also is no limit fine ?

I think it should have a limit.
And maybe it should be done in the background.
If there are many files this may slow down things.

Thanks @martin-g for reviewing.

Agree on having limit.

But doing it in background will result in inconsistent behavior ?

Should DataFusion collect statistics when first creating a table. Has no effect after the table is created. Applies to the default ListingTableProvider in DataFusion. Defaults to true.

Will a user not expect the statistics to be collected when creating the table and expect any query post that to be optimized based on the above documentation ?

datafusion/core/src/datasource/listing_table_factory.rs

martin-g · 2025-11-27T22:10:19Z

datafusion/core/src/datasource/listing_table_factory.rs

+
+        // Pre-warm statistics cache if collect_statistics is enabled
+        if session_state.config().collect_statistics() {
+            let _ = table.list_files_for_scan(state, &[], None).await?;


2. Also is no limit fine ?

I think it should have a limit.
And maybe it should be done in the background.
If there are many files this may slow down things.

…tion Signed-off-by: bharath-techie <bharath78910@gmail.com>

Signed-off-by: bharath-techie <bharath78910@gmail.com>

bharath-techie · 2025-11-30T07:26:43Z

Hi @martin-g @alamb ,

Can you help decide following to move the PR forward ?

The limit is based on number of rows, so we either we keep it as None or we make it configurable maybe ? If we are going to configuration route, I'm leaning towards keeping None as default as number of rows will vary based on data. Some users might have few columns, lots of rows and some vice versa.
- One use case is clickbench data, where we register partitions with ~99 million rows , and we want statistics of all files to be present for example.[ as given in parent issue https://github.com/Bug: statistics not collected automatically upon creation of ListingTable #18952 ]
Can you help decide whether to do this in background ? Doing it in sync path will be deterministic behavior I feel. Otherwise we need to update documentation to reflect the same.

martin-g · 2025-11-30T14:17:48Z

My concern is that if there are many files then the pre-warming of the cache may slow down the main operation. I am not sure how many is too many though.

But I guess you could leave it as is for now and optimize it only after there is an evidence that it really causes slow downs for someone.

alamb · 2025-11-30T20:41:41Z

Thank you @bharath-techie -- I am checking this one out

xudong963 · 2025-12-01T11:14:01Z

In our internal, we do stats collection in a separate task.

Background task is a good idea, but based on the current situation, the PR looks like the fastest way to have stats while creating table.

alamb · 2025-12-01T15:59:24Z

My concern is that if there are many files then the pre-warming of the cache may slow down the main operation. I am not sure how many is too many though.

But I guess you could leave it as is for now and optimize it only after there is an evidence that it really causes slow downs for someone.

Thanks @martin-g -- I do agree that is a concern. However, I think the idea is that any subsequent query is going to collect the statistics anyways, so this PR simply moves which statement triggers the collection

alamb · 2025-12-01T21:48:36Z

I took the liberty of pushing some commits that fixed the CI failures and merging up from main

alamb

Thank you @bharath-techie -- this makes sense to me 🙏

alamb · 2025-12-01T22:00:37Z

Thank you also @xudong963 and @martin-g for the reviews

In our internal, we do stats collection in a separate task.

@xudong963 is this something we should write down / document / implement? Maybe not the actual behavior of pre-fetching statistics in the background but some method or something to make it easier for others to call?

bharath-techie · 2025-12-02T03:51:29Z

Thanks @alamb for the review and changes :)

Also listing file statistics cache seems to not have any memory limit unlike metadata cache for example.

Is that by design , do you think we need to add similar limit for this cache too ?

xudong963 · 2025-12-02T05:28:20Z

is this something we should write down / document / implement? Maybe not the actual behavior of pre-fetching statistics in the background but some method or something to make it easier for others to call?

Yeah, I would open an issue for this later

alamb · 2025-12-02T19:58:18Z

Thanks @alamb for the review and changes :)

Also listing file statistics cache seems to not have any memory limit unlike metadata cache for example.

Is that by design , do you think we need to add similar limit for this cache too ?

I think it is an oversight and we should add a similar limit. @nuno-faria actually asked the same question here:

Add a way to show the contents of the FileStatisticsCache in datafusion-cli #18953 (comment)

I will file a subsequent ticket to track that as well

alamb · 2025-12-02T20:15:12Z

Filed a ticket to track limiting the statistics cache:

Add limit to DefaultFileStatisticsCache #19052

alamb · 2025-12-03T13:35:15Z

Thanks again @bharath-techie and @martin-g and @xudong963

github-actions bot added the core Core DataFusion crate label Nov 27, 2025

bharath-techie commented Nov 27, 2025

View reviewed changes

martin-g reviewed Nov 27, 2025

View reviewed changes

bharath-techie added 2 commits November 30, 2025 12:43

fix: pre-warm listing file statistics cache during listing table crea…

77a0548

…tion Signed-off-by: bharath-techie <bharath78910@gmail.com>

Handling error locally

50eaaf5

Signed-off-by: bharath-techie <bharath78910@gmail.com>

bharath-techie force-pushed the listing-table-fix branch from 8b8a49e to 50eaaf5 Compare November 30, 2025 07:13

alamb mentioned this pull request Nov 30, 2025

Andrew Lamb Weekly-ish Open Source plan - 2025-11-24 #18888

Closed

37 tasks

alamb mentioned this pull request Dec 1, 2025

Andrew Lamb Weekly-ish Open Source plan - 2025-12-01 #19016

Closed

42 tasks

alamb added 3 commits December 1, 2025 16:37

clippy

b4835bc

Merge remote-tracking branch 'apache/main' into listing-table-fix

83ff186

Use existing test file

1e5c88f

Add names for arguments so it is clear what is going on

c0857dd

alamb approved these changes Dec 1, 2025

View reviewed changes

alamb mentioned this pull request Dec 1, 2025

Add builder API for CreateExternalTable to reduce redundancy and make the code easier to understand #19039

Closed

alamb mentioned this pull request Dec 2, 2025

Add limit to DefaultFileStatisticsCache #19052

Open

xudong963 mentioned this pull request Dec 3, 2025

chore: Add TPCDS benchmarks #18985

Closed

nuno-faria mentioned this pull request Dec 3, 2025

feat: Implement the statistics_cache function #19054

Merged

alamb added this pull request to the merge queue Dec 3, 2025

Merged via the queue into apache:main with commit 4d86ae0 Dec 3, 2025
27 checks passed

Conversation

bharath-techie commented Nov 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Which issue does this PR close?

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

Uh oh!

bharath-techie Nov 27, 2025

Choose a reason for hiding this comment

Uh oh!

martin-g Nov 27, 2025

Choose a reason for hiding this comment

Uh oh!

bharath-techie Nov 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

martin-g Nov 27, 2025

Choose a reason for hiding this comment

Uh oh!

bharath-techie commented Nov 30, 2025

Uh oh!

martin-g commented Nov 30, 2025

Uh oh!

alamb commented Nov 30, 2025

Uh oh!

xudong963 commented Dec 1, 2025

Uh oh!

alamb commented Dec 1, 2025

Uh oh!

alamb commented Dec 1, 2025

Uh oh!

alamb left a comment

Choose a reason for hiding this comment

Uh oh!

alamb commented Dec 1, 2025

Uh oh!

bharath-techie commented Dec 2, 2025

Uh oh!

xudong963 commented Dec 2, 2025

Uh oh!

alamb commented Dec 2, 2025

Uh oh!

alamb commented Dec 2, 2025

Uh oh!

Uh oh!

alamb commented Dec 3, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

bharath-techie commented Nov 27, 2025 •

edited

Loading

bharath-techie Nov 28, 2025 •

edited

Loading