On Mon, Sep 8, 2025 at 5:09 PM Vivek Gadge <vvkgadge56@gmail.com> wrote:
>
>
> For example, when a query runs on a partitioned table, PostgreSQL scans partitions in the order they were created or
attachedto the parent table. In our case (monthly partitions from January through September), this means that queries
lookingfor 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
actuallycontain 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
pruningcannot 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
