On 8/9/2025 13:39, Vivek Gadge 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.
The case looks straightforward. But just to be sure that we are on the
same page, could you provide a synthetic DB example and a query
representing the exact problem you are going to resolve?
--
regards, Andrei Lepikhov
