Re: Query Performance Degradation Due to Partition Scan Order – PostgreSQL v17.6
От | Andrei Lepikhov |
---|---|
Тема | Re: Query Performance Degradation Due to Partition Scan Order – PostgreSQL v17.6 |
Дата | |
Msg-id | 404fa7e8-6490-4aff-8f2a-2d15a13433e0@gmail.com обсуждение исходный текст |
Ответ на | Re: Query Performance Degradation Due to Partition Scan Order – PostgreSQL v17.6 (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
Ответы |
Re: Query Performance Degradation Due to Partition Scan Order – PostgreSQL v17.6
Re: Query Performance Degradation Due to Partition Scan Order – PostgreSQL v17.6 |
Список | pgsql-hackers |
On 8/9/2025 11:47, Ashutosh Bapat wrote: > On Mon, Sep 8, 2025 at 4:01 AM Vivek Gadge <vvkgadge56@gmail.com> wrote: >> Looking forward to your guidance. >> >> Thank you >> > > Can you please describe how the query performance is affected because > of the order in which partitions are scanned? I guess they mentioned that the Postgres optimiser doesn't care about the order of Append's subplans. It is a little sad in some cases. The most critical case is when we have a limitation on the number of tuples returned. In this case, the optimiser could consider the following strategies: 1. Prefer scanning local partitions to foreign ones. 2. Pick first partitions with less startup costs and 'high probability' to obtain all necessary tuples from a minimum set of partitions. Postgres arranges clauses inside a long expression according to evaluation cost (see order_qual_clauses). So, why not do similar stuff for subplans? Also, I wonder if it would make sense to shuffle partitions a little and let backends scan partitions one-by-one in different orders just to reduce any sort of contention in case the queries don't fit the partitioning expression. -- regards, Andrei Lepikhov
В списке pgsql-hackers по дате отправления: