On Mon, Sep 8, 2025 at 5:09 PM Vivek Gadge <[email protected]> wrote: > > > For example, when a query runs on a partitioned table, PostgreSQL scans > partitions in the order they were created or attached to the parent table. In > our case (monthly partitions from January through September), this means that > queries looking for recent data (e.g., September) may experience additional > overhead. PostgreSQL evaluates the older partitions first, checking their > constraints and in some cases probing their indexes, before reaching the > later partitions that actually contain the needed data. > > As a result, while the query results are correct, the execution time > increases due to unnecessary work on irrelevant partitions. This performance > impact is more noticeable when the target partition is at the end of the scan > order and pruning cannot fully eliminate the earlier partitions. >
If you don't want data from certain partitions maybe you should add a clause that will help partition pruning. If you need data from all partitions, the order in which they are scanned doesn't matter, those will be scanned either way. If partitioning pruning isn't working for you, please report the exact query. Please provide example queries anyway. -- Best Wishes, Ashutosh Bapat
