@@ -1370,7 +1370,7 @@ config_namespace! {
 
         /// (reading) If true, filter expressions are be applied during the parquet decoding operation to
         /// reduce the number of rows decoded. This optimization is sometimes called "late materialization".
-        pub pushdown_filters: bool, default = false
+        pub pushdown_filters: bool, default = true
 
         /// (reading) If true, filter expressions evaluated during the parquet decoding operation
         /// will be reordered heuristically to minimize the cost of evaluation. If false,
@@ -1384,17 +1384,17 @@ config_namespace! {
         pub force_filter_selections: bool, default = false
 
         /// (reading) Controls the I/O pattern used when `pushdown_filters` is
-        /// enabled. If false (the default), all data pages needed to read a row
-        /// group (for both filter evaluation and the output projection) are
-        /// fetched in a single request, the same I/O pattern used when
-        /// `pushdown_filters` is disabled. If true, data is fetched
-        /// progressively: first the columns needed by each filter, then, after
-        /// the filters are evaluated, the remaining projected columns for the
-        /// rows that passed. Progressive fetching can reduce the total bytes
-        /// read when the file has a Parquet offset index, at the cost of
-        /// additional I/O requests per row group; files without an offset index
-        /// are always read with a single request per row group.
-        pub progressive_io: bool, default = false
+        /// enabled. If false, all data pages needed to read a row group (for
+        /// both filter evaluation and the output projection) are fetched in a
+        /// single request, the same I/O pattern used when `pushdown_filters` is
+        /// disabled. If true (the default), data is fetched progressively:
+        /// first the columns needed by each filter, then, after the filters are
+        /// evaluated, the remaining projected columns for the rows that passed.
+        /// Progressive fetching can reduce the total bytes read when the file
+        /// has a Parquet offset index, at the cost of additional I/O requests
+        /// per row group; files without an offset index are always read with a
+        /// single request per row group.
+        pub progressive_io: bool, default = true
 
         /// (reading) If true, parquet reader will read columns of `Utf8/Utf8Large` with `Utf8View`,
         /// and `Binary/BinaryLarge` with `BinaryView`.
 
@@ -26,8 +26,8 @@
 //! Two properties of the planner shape these queries, and both are easy to get
 //! wrong:
 //!
-//! * `execution.parquet.pushdown_filters` must be enabled. It defaults to
-//!   `false`, in which case no row filter is built and every case below
+//! * `execution.parquet.pushdown_filters` must be enabled (it is by
+//!   default). If it is disabled no row filter is built and every case below
 //!   degenerates to a plain scan.
 //! * The predicate must be a *single* conjunct. `build_row_filter` calls
 //!   `split_conjunction` before building filter candidates, and each candidate
 
@@ -162,9 +162,11 @@ mod tests {
             .select_columns(&["bool_col", "int_col"])?;
 
         let plan = df.explain(false, false)?.collect().await?;
-        // Filters all the way to Parquet
+        // Filters all the way to Parquet: with `pushdown_filters` enabled by
+        // default the predicate is evaluated by the scan itself
         let formatted = pretty::pretty_format_batches(&plan)?.to_string();
-        assert!(formatted.contains("FilterExec: id@0 = 1"), "{formatted}");
+        assert!(formatted.contains("predicate=id@0 = 1"), "{formatted}");
+        assert!(!formatted.contains("FilterExec"), "{formatted}");
 
         Ok(())
     }
 
@@ -322,11 +322,13 @@ mod tests {
 
         let plan = df.explain(false, false)?.collect().await?;
 
-        // Filters all the way to Parquet
+        // Filters all the way to Parquet: with `pushdown_filters` enabled by
+        // default the predicate is evaluated by the scan itself
         let formatted = arrow::util::pretty::pretty_format_batches(&plan)
             .unwrap()
             .to_string();
-        assert!(formatted.contains("FilterExec: id@0 = 1"));
+        assert!(formatted.contains("predicate=id@0 = 1"), "{formatted}");
+        assert!(!formatted.contains("FilterExec"), "{formatted}");
         Ok(())
     }
 
 
@@ -46,8 +46,8 @@
 //! The reason is that the extraction projection is the node a source absorbs.
 //! A Parquet scan merges it into the file projection and reads only the struct
 //! leaf. With the opposite precedence the scan reads the whole struct whenever
-//! `datafusion.execution.parquet.pushdown_filters` is `false`, which is the
-//! default. The filter loses nothing by staying one node higher, because
+//! `datafusion.execution.parquet.pushdown_filters` is `false`. The filter
+//! loses nothing by staying one node higher, because
 //! `PushDownFilter` records the predicate in
 //! [`TableScan::filters`](datafusion_expr::logical_plan::TableScan) in the pass
 //! that runs before the extraction projection exists, so row group pruning and