BlakeOrth commented on code in PR #19616:
URL: https://github.com/apache/datafusion/pull/19616#discussion_r2669645181
##########
datafusion/execution/src/cache/list_files_cache.rs:
##########
@@ -350,23 +358,40 @@ impl ListFilesCache for DefaultListFilesCache {
state.evict_entries();
}
- fn list_entries(&self) -> HashMap<Path, ListFilesEntry> {
+ fn list_entries(&self) -> HashMap<TableScopedPath, ListFilesEntry> {
let state = self.state.lock().unwrap();
- let mut entries = HashMap::<Path, ListFilesEntry>::new();
+ let mut entries = HashMap::<TableScopedPath, ListFilesEntry>::new();
for (path, entry) in state.lru_queue.list_entries() {
entries.insert(path.clone(), entry.clone());
}
entries
}
+
+ fn drop_table_entries(
+ &self,
+ table_ref: &Option<TableReference>,
+ ) -> datafusion_common::Result<()> {
+ let mut state = self.state.lock().unwrap();
+ let mut table_paths = vec![];
Review Comment:
My understanding is the same as @jizezhang, I think the most common case
will be a singe path per table, additionally `Vec<Path>` is effectively
`Vec<String>` so I would never expect the actual memory allocated for the `Vec`
itself to be very large.
That being said, it does look like we just end up needing a reference
`&path`, so if we could avoid the `path.clone()` call that seems like it would
be a nice improvement.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
